MDN Playground

https://developer.mozilla.org/en-US/play

by weinzierl • 3 years ago

232 100 3 years ago

developer.mozilla.org

mintaka52• 3 years ago

just for the record MDN's site, hands down, has the best documentation ever made by any agent of the programming industry

bsmth2• 3 years ago

Thank you for sharing, feedback like this is a great to see :)

dgb23• 3 years ago

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.

edlucas• 3 years ago

Kagi search also supports this bang shortcut, which I find very handy.

mintaka52• 3 years ago

such a great resource and i have much respect for the devs of this site, to go to such a level quality, that it makes it easier for all of us to accomplish great things =)

krono2• 3 years ago

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 ;)

[0] https://html.spec.whatwg.org/

[1] https://262.ecma-international.org/14.0/

bazoom42• 3 years ago

Those specs need to be extremely detailed to ensure interoperability. Earlier versions of the HTML specs were much more readable, but unfortunately lead to interoparability issues.

recursive4• 3 years ago

In some (rare) cases, I find that MDN doesn't have enough detail. Official specs aren't as easy, but I can usually track down any specific behavior detail in 10 or 15 minutes. For the degree of precision provided, I really think this is not bad at all.

chrismorgan3• 3 years ago

The HTML Standard is excellent. It’s long and verbose because of the mountains of accumulated cruft it covers, so that it takes a little getting used to if you’re not familiar with the style, but it’s a magnificent document for finding specific answers in. I refer to it regularly, by choice, as a web developer and not a browser maker. There are large chunks of it that are really valuable reading for normal web developers. I still thoroughly appreciate MDN, but for HTML I could do without it without much trouble, the HTML Standard is good enough, even though it’s targeted primarily at implementers.

CSS specs are likewise very readable and extremely useful reference, though they’re less precise than significant parts of the HTML Standard. But if you have questions about how certain things fit together, or corner cases in certain properties, MDN is normally useless while the relevant specs are regularly invaluable. I highly recommend being familiar with reading these specs if you’re doing even mildly unconventional things.

The ECMAScript Language Specification: it’s not like either of the other two; it’s not a document that describes how things are supposed to act or how to use things, but is full code for implementing an ECMAScript engine—just expressed in natural language rather than a more accustomed programming language. I’ve referred to it a number of times when I’ve had nuanced questions about exactly what the engine does in such-and-such a case (the sort that the vast majority of web developers will never need or want to ask), and it’s been useful in such cases once it finally loaded, but it’s very firmly designed for implementers, not users. Covering any of the sort of stuff that MDN covers in documentation was never anywhere near the intended scope of the ECMAScript Language Specification, nor should it have been.

The specs and MDN serve quite different purposes, and something that combined both functions would be poor at both functions. Bemoan not the necessity of either: rejoice rather that you have both!

raincole• 3 years ago

Especially considering they are facing an unusual hassle: browsers' compatibility (which is completely out of their control).

thrdbndndn• 3 years ago

I do found more minor errors in MDN compared to other official documentation (like Python), but it's kinda understandable.

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.

Xenoamorphous• 3 years ago

Yet for some reason w3schools ranks higher in Google for many queries.

Phemist4• 3 years ago

The exact reason why you need some control over your search engine results.

For me, I have blackholed w3schools and boosted MDN in my search engine of choice. It is quite nice to always get the MDN page on a web-dev related query as the top result.

Even searching for "w3schools" directly results in the wikipedia as the top result (which is.. fair enough).

The same search on DDG results is a page full of w3schools & subdomains.

lucideer2• 3 years ago

There's 2 pretty reasonable reasons for this:

1. MDN's quality is higher, and it's more comprehensive when it comes to new browser specifications, but it's much less comprehensive in general technology/programming topics (e.g. W3Schools covers PHP which many working with e.g. Wordpress will dabble in alongside their HTML/CSS/JS).

2. Tenure. MDN's is much much more recent - W3Schools has been around forever.

W3Schools is a somewhat dodgy website with questionable quality, but it's hard to argue they've had a net-negative impact on educating programmers. I certainly learned a large chunk of my knowledge from W3Schools in the days before MDN docs existed in their current form.

timvisee2• 3 years ago

Then you haven't seen Rust's documentation yet.

https://doc.rust-lang.org/std/index.html

lytedev• 3 years ago

I'm partial to Elixir's documentation myself: https://hexdocs.pm/ecto/Ecto.html

sjsanc• 3 years ago

Compare MDN's entry for the `map` method

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

With Rust's

https://doc.rust-lang.org/std/iter/struct.Map.html

I find MDN to be a bit clearer, and they benefit from the in-browser runtime. All the extra detail in the Rust docs (blanket traits etc) were quite intimidating and distracting when I first started learning it.

bob1029• 3 years ago

The quality of MDN gave me enough confidence to move away from frameworks and take matters into my own hands.

IshKebab• 3 years ago

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.

catsarebetter• 3 years ago

The AI Help feature looks super interesting, any plans to integrate it into the playground?

jai_2• 3 years ago

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.

[1] https://developer.mozilla.org/en-US/plus/ai-help

hagreet2• 3 years ago

Please no. The site is an important resource for people learning JS and other web technologies and AI is great at explaining code snippets which would otherwise be follow-up look-ups and at explaining what the often very dense MDN content means. And AI is actually really good at generating code as well, you just have to review it like it was written by a junior dev.

I think most of the hate for current AI tools comes from the fact that people expect the computer from Star Trek which always provides perfect answers.

Edit: So yes, it needs to be made super obvious to users that it might give you wrong answers.

capableweb• 3 years ago

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.

jerrygoyal• 3 years ago

I liked that it is lightweight than codesandbox, stackblitz etc.Also, surprised that it has intellisense but it doesn't work for `console.log`.

qsort• 3 years ago

It's something more like jsfiddle than a full-blown dev environment like codesandbox or stackblitz.

mg• 3 years ago

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:

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.

sintaxi• 3 years ago

Agreed. Great job.

cetinsert3• 3 years ago

https://RTCode.io is our single-pane, reload-free, HTML/CSS/JS playground!

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)

xyby• 3 years ago

Does not work at all for me.

Is this a commercial product?

AndroidKitKat• 3 years ago

This is very nice, and I can see myself using this in the future. However, I have one slight piece of feedback; is there any chance you can make the delay on the menus flying out and tooltips just appearing all over the place when I move my cursor just a little bit longer? I felt like I was getting bombarded with information by just wanting to move my cursor to the other pane.

Besides that, I like it. Thanks for the links.

gpmcadam• 3 years ago

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.

toyg5• 3 years ago

It makes more sense if you think that an HTML is a static document, which then gets decorated by CSS, and lightly animated by JS.

That is what the web was built as. We were supposed to browse documents like we browsed magazines. Your React monstrosities were hacked on top of that model, turning the browser into an application runtime - which it wasn't meant to be.

lelanthran3• 3 years ago

I think the real problem is that CSS mixes in two many different concerns.

If I want to create a reusable component I need to control the layout tightly, and use media queries for display size.

The user of the component needs to control the colour and cosmetic stuff, while also using media queries, but for dark/light mode.

All four use cases use the same bloody input - CSS! Which means all of the different parties are stepping on each others toes because they may accidentally set a property that needs to be set by a different party.

It's not designed for separation of concerns.

bityard• 3 years ago

There is no one rule that fits all projects, this is what being an "engineer" is all about. If there were hard and fast rules for building applications, all of us here would either be out of a job, or doing the software equivalent of working on an assembly line.

However, my own personal guidelines are::

* A small project lives all in one file.

* A medium project is organized by what the files are (markup, images, etc).

* A large project is organized by its major components, and how those components are themselves organized depends on _their_ size and what they do.

* Never be afraid to reorganize a project if (and only if) it makes sense.

CharlesW• 3 years ago

…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.

This is why I absolutely love Vue single-file components. AFAIK, there’s no elegant substitute for these in React.

https://vuejs.org/guide/scaling-up/sfc.html

lelanthran3• 3 years ago

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.

tomcam• 3 years ago

Yes cubed! Thank you.

viraptor• 3 years ago

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.

8n4vidtmkvmk4• 3 years ago

Yes, the placement of the script tag very much matters, but it's most likely after your html or deferred to run after your html, in which case... Not really.

There is one little quirky js thing you can do to get the script element from inside the script but I doubt many people are doing that.

recursive4• 3 years ago

Sometimes yes, sometimes no.

Etheryte• 3 years ago

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.

fiji-flo2• 3 years ago

Great catch, should be fixed with our nightly (UTC) deployment.

anon35• 3 years ago

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.

chrisweekly• 3 years ago

Great comment.

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• 3 years ago

I work at ${bigCorp} and am not allowed to use playgrounds :(

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.

recursive4• 3 years ago

You could make your own out of a static file. You could even give it a "boss key" to make it show some very corporate looking spreadsheets or something.

razodactyl• 3 years ago

It's called find a new job and never look back.

fastball• 3 years ago

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.

cassepipe• 3 years ago

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

8n4vidtmkvmk4• 3 years ago

"install" the web page. That opens up more keyboard shortcuts.

toinewx• 3 years ago

so basically codepen

pdmccormick• 3 years ago

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!

msoad• 3 years ago

They have to solve the problems JSBin and like solved years ago all over again. Starting with infinite loops ;)

ogaistan2• 3 years ago

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.

[1] https://www.jsplayground.dev [2] https://babeljs.io

fiji-flo2• 3 years ago

Here's the announcement blog post for some context: https://developer.mozilla.org/en-US/blog/introducing-the-mdn...

spread_love• 3 years ago

Freemium teaser?

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.

ogaistan2• 3 years ago

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.

[1] https://www.jsplayground.dev

KRAKRISMOTT• 3 years ago

Any chance emmet and autocompletion can be added for the editor?

max23_• 3 years ago

Nice to see this from MDN. My go to playground has been jsfiddle, will start using this.

mkhizar53• 3 years ago

shows why simple works

spankalee• 3 years ago

If you ever want to add a client-side-only playground to your own site, have a look at the Playground Elements project: https://github.com/google/playground-elements

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.

MDN Playground

Related Stories