| As I said in the other comment: jsgist, precisely because it's so bare-bones. The data is stored either in a shareable URL parameter, or in a gist if you give it access to you GH account. Everything else is a minimal PWA in a static html file that makes hosting of it super-cheap, so I don't have to worry about greggman pulling it down. Anyway, the main uses case I see for these playground sites are: 1) small hand-crafted replications of suspected browser CSS bugs or the like, and testing possible workarounds. That often involves sending them to other members in the team (because I use Linux and Android, two colleagues in the team use Windows, and two using Apple products) 2) trying out some idea for how to make a particular component. Which is effectively almost the same as above, since that needs to be tested across browsers. So I don't need bells and whistles beyond a simple text editor with code folding. That might not apply to everyone else. Also, the exact same line of thought applies to js benchmarking sites, which is why I use jsbenchit (which is jsgist but for benchmarks). It also seems to be one of the few benchmarking sites without spurious de-opts of JS code, or noise from GCs triggered by the website itself in the middle of a benchmarking run. [0] https://jsgist.org/, https://github.com/greggman/jsgist/ [1] https://jsbenchit.org/, https://github.com/greggman/jsbenchit/ |