For some reason, I never liked that all the code playgrounds have separate windows for HTML, CSS and Javascript. It makes it hard to grok what is going on. Does the CSS and JS get injected into the HTML? Is it loaded via injected <script> and <link> tags?
I'm also never sure what magic gets wrapped around the html I type. Does this thing add a DOCTYPE? A header? Or can I define my own header? Etc.
So I made this one, where you edit just a raw html page and see the output right away:
One way I often use it is that I copy the whole source (via view source) of a page, paste it into the html_editor, add a <base href="url_of_the_page"> to it and then I can try realtime changes with all the external CSS and JS being loaded just as it is on the original page.
One of the strangest things to infect the web development community was that separation of concerns somehow meant separation of HTML/JS/CSS, which to me always felt like the opposite since very often the HTML, the JS and the CSS were all very much concerned with one another e.g. a React component where the rendered HTML, the logic behind it and how it's styled make sense to live next to one another.
I think it's for this reason you often see those languages split out in code playgrounds. And I also think it's a big part of the initial pushback against css-in-JS libraries such as styled-components or Emotion.
> Does the CSS and JS get injected into the HTML? Is it loaded via injected <script> and <link> tags?
Does it matter? (Serious question) Not for a full website where it matters for duplication / caching / performance, but in this context - for the playground.
> or some reason, I never liked that all the code playgrounds have separate windows for HTML, CSS and Javascript. It makes it hard to grok what is going on. Does the CSS and JS get injected into the HTML? Is it loaded via injected <script> and <link> tags?
Tbh I also never liked it, for all those reasons you listed.
Ideally it would be a left panel with a treeview list of files with the selected file displayed on the right panel in an editable element.
Output should be a different window which updates on every change.
It's not only a great reference documentation, it also has comprehensive guides for both beginners and advanced developers. Including niche/complex features like canvas, webrtc, service workers etc.
In a web programming course I created I often referred to and leaned on MDN.
Aside:
DDG lets you search in MDN directly if you prefix a search with !mdn. It's one of the few sites that has a very much usable search feature.
I disagree. It's very good. Far above average. But there's still a decent number of times I find missing details.
If we're talking the best then it has to compete with Qt, Rust, MSDN, cppreference, all of which I would say are better. Definitely in the top 10 though.
The site is an absolute godsend, but it's also quite sad that the various standards specifications MDN covers have such terrible documentation websites of their own, that something like what MDN offers is even needed at all!
Just look at the official HTML and JavaSc.. nay, ECMAScript specification docs[0][1]. You'd sooner end up with a headache than a functional website if you had no other choice but to use those ;)
Great to see. More generally: I feel like playgrounds are grossly underused in our industry. It's possible the issue is in the name -- it immediately connotes that whatever you're doing isn't real work, it's just a place to, well, "play".
But really these kind of playgrounds are at least a cousin, if not a direct descendant, of the immediate feedback principle that underlies everything from a REPL to the kind of systems (Symbolics, etc) that allow you to edit running code. Their potential is beautifully illustrated in Brett Victor's famous 'Inventing on Principle' talk: https://www.youtube.com/watch?v=PUv66718DII
Three areas that I'd love to see playgrounds mature beyond teaching beginners CSS:
1) Integrated directly into developer documentation. You can see some of that in systems that are documenting services -- for example, the Google Sheets API documentation has a 'Try this Method' box that lets you post a request to the service on the same page that describes it, but what I really want is something like that when I'm reading the man page of a destructive disk command, or a complex database query, or a low-level C graphics library. That'll require a playground wired to something as big as a VM, maybe.
2) Integrated into textbooks: for the last couple years the astonishing posts from Bartosz Ciechanowski ([Sound](https://ciechanow.ski/sound/), [Bicyle](https://ciechanow.ski/bicycle/)) have demonstrated just how much better a textbook could be if you could interactively play with the concepts you're reading about. Unlike dev docs, the thing you're interacting with doesn't even have to be "real".
3) Most ambitiously: integrated into the input form of bug/issue tracking tools. This is the opposite of play: it means a running system would need to be in cahoots with a playground, so that mature apps could let you record and playback what you saw as a user, allow you to edit irrelevant parts of input and output out and submit a complete here-look-see-it-is-busted asset for analysis. A Stackoverflow of the future would be orders of magnitude more interesting if each question was posed as a broken playground.
I would pay a monthly subscription for a playground that makes it very easy for me to quickly prototype and test across different browsers.
For quick JS prototyping I use RunJS a fair bit, but it is purely for JS so I can't test HTML/CSS. I've also tried Quokka for the same use case but it didn't work very well for me either (having to create files in my editor actually felt kinda annoying somehow).
I also do a decent amount of performance benchmarking, but all the websites for that right now are pretty meh (takes a while to figure out how to get libs imported, assuming they actually work, seems many JS benching sites are abandoned). And most of all they only test in my browser. While building the test suite that's good, but once I'm happy with it I'd like to be able to click a button which will bench my suite in Chrome / Firefox / Safari.
Related thoughts: "design systems" / UI component libraries often have interactive documentation sites (e.g. built with Storybook), showcasing variants and providing "knobs" / controls to edit props and see the results in realtime, so lib consumers can see a component working (in isolation) and generate a code fragment copy/pasteable into their own downstream app.
Also, extending your item (3), project maintainers often ask people reporting bugs to provide an MRE (Minimum Reproducable Example) in a standalone repo. I've noticed a few such cases where the maintainers make this much easier by sharing a link to a basic preconfigured codesandbox or stackblitz for exactly this MRE purpose. I think this idea will catch on and become much more common.
Last week I signed up for an annual subscription to MDN. I didn’t realize it at the time, but paying subscribers get the option to enable offline mode (it currently downloads about 630 MiB of content). I generally have fast connections wherever I’m working, but the difference between “fast” and “instant” when loading new pages is really making the experience feel special for me. I would heartily suggest you support MDN and try it out!
It's a set of custom elements and a service worker that populate an iframe with the contents of the code editor with no server, but in a way that looks like real network requests to the iframe.
This means you get a root HTML page and all the right loading behavior and ordering as a real hosted web page. Inspect the iframe with devtools and you see exactly what you wrote, nothing added by the playground.
The elements also support Node-style import specifier resolution, pulling npm dependencies automatically from unpkg.com, TypeScript, and JSX.
And the elements are very configurable. You have drop in a tabbed-editor and preview combo element, or you can separate the preview and editors for each file - which lets you write prose around each.
I really spend more time than I thought I would be (in this age of JS frameworks) using dead simple HTML, CSS, JS playgrounds for quick prototyping and iteration.
I did eventually end up building one for myself and made it available [1] that the goal was a clean UI/UX, minimal and instant live feedback loop with no extra calls to the server - just a simple static website. It defaults to a JS playground since it's what I use the most but HTML and CSS can be toggled.
I sincerly hope that they remove this feature and apologise for its integration in the first place.
I don't think a reference website should include any sort of feature that can hallucinate incorrect documentation for you on demand.
It's bad enough that they have to include a disclaimer[1] on their upsell page, which states that the "AI Help" may occassionally return incorrect results.
Small bug report: 1) Clear the site data so you don't have a saved playground preloaded. 2) Focus the Javascript text area and type a singular "f", nothing more, nothing less, no other interactions. 3) The playground compiles, the cursor position in the Javascript text area is reset incorrectly.
Funny that you mentioned this as I added some heuristics to my playground [1] yesterday for this use case. It relies on Babel [2] which looks for `for`, `while` and `do-while` loops and injects a counter that throws an 'infinite loop detected' error to prevent the browser freezing. You can opt out if you know what you are doing. It's not perfect, but it covers this base cases.
Not sure if it's a bug or not, but the JavaScript editor seems to only try to autocomplete reserved keywords and not much more, unlike the HTML and CSS editor. I'd expect it to show me at least functions available at window., document. and console. , as an example.
My problems with all those playgrounds is that I don't know where shortcuts are and when there are shortcuts, it's full of Ctrl combination that may clash with the browser...
Can I has a vim mode please ? I am not returning back to using arrows to move around text
[+] [-] mg|2 years ago|reply
I'm also never sure what magic gets wrapped around the html I type. Does this thing add a DOCTYPE? A header? Or can I define my own header? Etc.
So I made this one, where you edit just a raw html page and see the output right away:
https://no-gravity.github.io/html_editor/
The code is here:
https://github.com/no-gravity/html_editor
One way I often use it is that I copy the whole source (via view source) of a page, paste it into the html_editor, add a <base href="url_of_the_page"> to it and then I can try realtime changes with all the external CSS and JS being loaded just as it is on the original page.
[+] [-] gpmcadam|2 years ago|reply
I think it's for this reason you often see those languages split out in code playgrounds. And I also think it's a big part of the initial pushback against css-in-JS libraries such as styled-components or Emotion.
[+] [-] cetinsert|2 years ago|reply
Video: https://rt.ht/yt (multi-device, live sync without reloads)
Home: https://elefunc.com/#rtcode_io
Playground: https://rtcode.io
Network: https://rtedge.net
---
To import from CodePen:
• https://codepen.io/jkantner/pen/NWEgzoK (original)
• https://rt.ht/codepen.io/jkantner/pen/NWEgzoK (import)
• https://rtcode.io/jkantner/pen/NWEgzoK (import)
[+] [-] viraptor|2 years ago|reply
Does it matter? (Serious question) Not for a full website where it matters for duplication / caching / performance, but in this context - for the playground.
[+] [-] lelanthran|2 years ago|reply
Tbh I also never liked it, for all those reasons you listed.
Ideally it would be a left panel with a treeview list of files with the selected file displayed on the right panel in an editable element.
Output should be a different window which updates on every change.
[+] [-] sintaxi|2 years ago|reply
[+] [-] tomcam|2 years ago|reply
[+] [-] mintaka5|2 years ago|reply
[+] [-] dgb23|2 years ago|reply
In a web programming course I created I often referred to and leaned on MDN.
Aside:
DDG lets you search in MDN directly if you prefix a search with !mdn. It's one of the few sites that has a very much usable search feature.
[+] [-] Xenoamorphous|2 years ago|reply
[+] [-] thrdbndndn|2 years ago|reply
And it sometimes takes months to get things fixed (after reporting or providing PR at https://github.com/mdn/content).
I've learned to always test myself when it comes to pesky/obscure behavior(s) of JS.
[+] [-] bsmth|2 years ago|reply
[+] [-] IshKebab|2 years ago|reply
If we're talking the best then it has to compete with Qt, Rust, MSDN, cppreference, all of which I would say are better. Definitely in the top 10 though.
[+] [-] timvisee|2 years ago|reply
https://doc.rust-lang.org/std/index.html
[+] [-] krono|2 years ago|reply
Just look at the official HTML and JavaSc.. nay, ECMAScript specification docs[0][1]. You'd sooner end up with a headache than a functional website if you had no other choice but to use those ;)
[0]: https://html.spec.whatwg.org/
[1]: https://262.ecma-international.org/14.0/
[+] [-] raincole|2 years ago|reply
[+] [-] bob1029|2 years ago|reply
[+] [-] anon35|2 years ago|reply
But really these kind of playgrounds are at least a cousin, if not a direct descendant, of the immediate feedback principle that underlies everything from a REPL to the kind of systems (Symbolics, etc) that allow you to edit running code. Their potential is beautifully illustrated in Brett Victor's famous 'Inventing on Principle' talk: https://www.youtube.com/watch?v=PUv66718DII
Three areas that I'd love to see playgrounds mature beyond teaching beginners CSS:
1) Integrated directly into developer documentation. You can see some of that in systems that are documenting services -- for example, the Google Sheets API documentation has a 'Try this Method' box that lets you post a request to the service on the same page that describes it, but what I really want is something like that when I'm reading the man page of a destructive disk command, or a complex database query, or a low-level C graphics library. That'll require a playground wired to something as big as a VM, maybe.
2) Integrated into textbooks: for the last couple years the astonishing posts from Bartosz Ciechanowski ([Sound](https://ciechanow.ski/sound/), [Bicyle](https://ciechanow.ski/bicycle/)) have demonstrated just how much better a textbook could be if you could interactively play with the concepts you're reading about. Unlike dev docs, the thing you're interacting with doesn't even have to be "real".
3) Most ambitiously: integrated into the input form of bug/issue tracking tools. This is the opposite of play: it means a running system would need to be in cahoots with a playground, so that mature apps could let you record and playback what you saw as a user, allow you to edit irrelevant parts of input and output out and submit a complete here-look-see-it-is-busted asset for analysis. A Stackoverflow of the future would be orders of magnitude more interesting if each question was posed as a broken playground.
[+] [-] fastball|2 years ago|reply
For quick JS prototyping I use RunJS a fair bit, but it is purely for JS so I can't test HTML/CSS. I've also tried Quokka for the same use case but it didn't work very well for me either (having to create files in my editor actually felt kinda annoying somehow).
I also do a decent amount of performance benchmarking, but all the websites for that right now are pretty meh (takes a while to figure out how to get libs imported, assuming they actually work, seems many JS benching sites are abandoned). And most of all they only test in my browser. While building the test suite that's good, but once I'm happy with it I'd like to be able to click a button which will bench my suite in Chrome / Firefox / Safari.
[+] [-] chrisweekly|2 years ago|reply
Related thoughts: "design systems" / UI component libraries often have interactive documentation sites (e.g. built with Storybook), showcasing variants and providing "knobs" / controls to edit props and see the results in realtime, so lib consumers can see a component working (in isolation) and generate a code fragment copy/pasteable into their own downstream app.
Also, extending your item (3), project maintainers often ask people reporting bugs to provide an MRE (Minimum Reproducable Example) in a standalone repo. I've noticed a few such cases where the maintainers make this much easier by sharing a link to a basic preconfigured codesandbox or stackblitz for exactly this MRE purpose. I think this idea will catch on and become much more common.
[+] [-] evandale|2 years ago|reply
Additionally my company won't run their own playground because they can't figure out how to store and audit code people put into it.
[+] [-] pdmccormick|2 years ago|reply
[+] [-] spankalee|2 years ago|reply
It's a set of custom elements and a service worker that populate an iframe with the contents of the code editor with no server, but in a way that looks like real network requests to the iframe.
This means you get a root HTML page and all the right loading behavior and ordering as a real hosted web page. Inspect the iframe with devtools and you see exactly what you wrote, nothing added by the playground.
The elements also support Node-style import specifier resolution, pulling npm dependencies automatically from unpkg.com, TypeScript, and JSX.
And the elements are very configurable. You have drop in a tabbed-editor and preview combo element, or you can separate the preview and editors for each file - which lets you write prose around each.
[+] [-] fiji-flo|2 years ago|reply
[+] [-] ogaistan|2 years ago|reply
I did eventually end up building one for myself and made it available [1] that the goal was a clean UI/UX, minimal and instant live feedback loop with no extra calls to the server - just a simple static website. It defaults to a JS playground since it's what I use the most but HTML and CSS can be toggled.
[1] https://www.jsplayground.dev
[+] [-] catsarebetter|2 years ago|reply
[+] [-] jai_|2 years ago|reply
I don't think a reference website should include any sort of feature that can hallucinate incorrect documentation for you on demand.
It's bad enough that they have to include a disclaimer[1] on their upsell page, which states that the "AI Help" may occassionally return incorrect results.
[1]: https://developer.mozilla.org/en-US/plus/ai-help
[+] [-] jerrygoyal|2 years ago|reply
[+] [-] qsort|2 years ago|reply
[+] [-] Etheryte|2 years ago|reply
[+] [-] fiji-flo|2 years ago|reply
[+] [-] msoad|2 years ago|reply
[+] [-] ogaistan|2 years ago|reply
[1] https://www.jsplayground.dev [2] https://babeljs.io
[+] [-] capableweb|2 years ago|reply
[+] [-] cassepipe|2 years ago|reply
Can I has a vim mode please ? I am not returning back to using arrows to move around text
[+] [-] 8n4vidtmkvmk|2 years ago|reply
[+] [-] spread_love|2 years ago|reply
I'd monetize this by adding features and hiding them behind MDN Pro+ (or w/e the subscription is called) in the future. Ala Codepen.
[+] [-] max23_|2 years ago|reply
[+] [-] KRAKRISMOTT|2 years ago|reply
[+] [-] mkhizar53|2 years ago|reply
[+] [-] toinewx|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Pixie_Dust|2 years ago|reply
[deleted]