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.
I made https://jsmess.com as one of my first vibe code projects and have been incrementally improving it over time when I have leftover tokens...
It's closest to JSFiddle but completely static, hosted on GitHub pages. No server side processing. Projects are private, saved on localstorage and can be shared via encoded URLs.
This has been a really fun way to ramp up with LLM based coding and I learned a ton, and made a tool I actually use quite often.
https://jsbin.com is what I've used since forever, it's fast and easy, used to use JSFiddle before that. I think you used to be able to create "bins" without having to login way back though. Honestly don't find much use for them anymore nowadays, if I want to share any web/web-like I do it via my own servers + domain and send links to people.
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/