MDN Playground(developer.mozilla.org)
developer.mozilla.org
MDN Playground
https://developer.mozilla.org/en-US/play
102 comments
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.
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.
> …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
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
Not trying to start a flame war but what can you do with these that can't be accomplished with React and e.g. https://styled-components.com ?
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.
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.
> All four use cases use the same bloody input - CSS!
All of the four mentioned use cases are stylistic. So it is desirable to accomplish them in a domain-specific styling language.
Used correctly, conflicting regressions are greatly minified.
It's just the problem with CSS that the vast number of developers don't know about its fundamentals, such as "CSS Specifity"
https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
This collective lack of knowledge leads to the kind of "monkey patching until it works for me (and breaks for you)" many lament about.
Feel free to give an concrete minimum viable example (including code) where you are struggling with CSS, and I will try to give suggestions.
All of the four mentioned use cases are stylistic. So it is desirable to accomplish them in a domain-specific styling language.
Used correctly, conflicting regressions are greatly minified.
It's just the problem with CSS that the vast number of developers don't know about its fundamentals, such as "CSS Specifity"
https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
This collective lack of knowledge leads to the kind of "monkey patching until it works for me (and breaks for you)" many lament about.
Feel free to give an concrete minimum viable example (including code) where you are struggling with CSS, and I will try to give suggestions.
> All of the four mentioned use cases are stylistic.
I respectfully disagree.
CSS controls layout of child components within a container, which is not a stylistic use case.
I've used Qt, WxWidgets, Tk, Delphi, VB and more, and none of them treat layout as a characteristic identical in nature to (for example) background-color.
Finagling the layout manager in any UI toolkit uses a very different mechanism from specifying the colors to use.
> Used correctly, conflicting regressions are greatly minified.
Maybe. I dunno if it is reasonable that the human reader can know all the CSS styles and files, and still not be able to tell which style will eventually be applied, because all of them have a '!' somewhere. > Feel free to give an concrete minimum viable example (including code) where you are struggling with CSS, and I will try to give suggestions.
I'm not really struggling; I find it weird, that is all - I think it is a mixing of concerns when the mechanism used to specify the location of (for example) the major page elements (menubar, leftnav, maincontent, rightnav)is the same as the mechanism to specify the background-color.
I respectfully disagree.
CSS controls layout of child components within a container, which is not a stylistic use case.
I've used Qt, WxWidgets, Tk, Delphi, VB and more, and none of them treat layout as a characteristic identical in nature to (for example) background-color.
Finagling the layout manager in any UI toolkit uses a very different mechanism from specifying the colors to use.
> Used correctly, conflicting regressions are greatly minified.
Maybe. I dunno if it is reasonable that the human reader can know all the CSS styles and files, and still not be able to tell which style will eventually be applied, because all of them have a '!' somewhere. > Feel free to give an concrete minimum viable example (including code) where you are struggling with CSS, and I will try to give suggestions.
I'm not really struggling; I find it weird, that is all - I think it is a mixing of concerns when the mechanism used to specify the location of (for example) the major page elements (menubar, leftnav, maincontent, rightnav)is the same as the mechanism to specify the background-color.
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.
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.
Frankly it doesn't matter what it was meant to be, and it doesn't help at all thinking about it as a way completely separate from reality.
Web/JS did what Java tried to do, a runtime that works on all platforms. The problem is that its too heavy weight. But platform lockdown will prevent any competition.
That’s a misreading of history. Here’s the announcement for JavaScript, which was posted here just yesterday[0]:
It says,
> MOUNTAIN VIEW, Calif. (December 4, 1995) -- Netscape Communications Corporation (NASDAQ: NSCP) and Sun Microsystems, Inc. (NASDAQ:SUNW), today announced JavaScript, an open, cross-platform object scripting language for the creation and customization of applications on enterprise networks and the Internet.
(Emphasis mine)
JavaScript was always meant for building applications.
[0] https://news.ycombinator.com/item?id=36782761
It says,
> MOUNTAIN VIEW, Calif. (December 4, 1995) -- Netscape Communications Corporation (NASDAQ: NSCP) and Sun Microsystems, Inc. (NASDAQ:SUNW), today announced JavaScript, an open, cross-platform object scripting language for the creation and customization of applications on enterprise networks and the Internet.
(Emphasis mine)
JavaScript was always meant for building applications.
[0] https://news.ycombinator.com/item?id=36782761
Even assuming JS that was originally meant for hover effects (or "rollover") and other "light animation", complex web applications predate React by a lot.
Think Outlook Web, Google Maps, and all the smaller apps built with frameworks of their time such as Dojo, YUI etc
There also are monstrosities with the server at the center...
applications with hundreds of hidden form fields per page, required server sessions for anonymous users, DSLs in half-baked server-side templating languages, server code generating and injecting opaque JS to sync state with the client, the list goes on.
And these things all have ups and downs themselves I guess, just like React has.
In fact animation is one of my least favorite uses of JS, the more I can do in CSS, the better.
As a user sometimes I enjoy complex animations but only when it serves a purpose.
Think Outlook Web, Google Maps, and all the smaller apps built with frameworks of their time such as Dojo, YUI etc
There also are monstrosities with the server at the center...
applications with hundreds of hidden form fields per page, required server sessions for anonymous users, DSLs in half-baked server-side templating languages, server code generating and injecting opaque JS to sync state with the client, the list goes on.
And these things all have ups and downs themselves I guess, just like React has.
In fact animation is one of my least favorite uses of JS, the more I can do in CSS, the better.
As a user sometimes I enjoy complex animations but only when it serves a purpose.
Those applications were meant to run on the server, more precisely on the Netscape proprietary appserver. On the browser they were meant to do popups and basic form validation at best. There was not even a network communication mechanism!
This is not what was intended. Just read the 1995 announcement - straight from the horse’s mouth. It was clear that Netscape had big plans for this. JS had its limitations, sure, but it could talk to Java on the client - which certainly did have network access. And famously, Microsoft felt so threatened by this new “platform” that they feared it would make Windows redundant. The late 90s was a wild ride.
> JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers. While Java is used by programmers to create new objects and applets, JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server. JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications.
> JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers. While Java is used by programmers to create new objects and applets, JavaScript is designed for use by HTML page authors and enterprise application developers to dynamically script the behavior of objects running on either the client or the server. JavaScript is analogous to Visual Basic in that it can be used by people with little or no programming experience to quickly construct complex applications.
You just have to read that to see how JS was just meant as a bit of glue between JDK and html pages. Java would do the heavy lifting everywhere.
Yes but you understand that the JDK was running in the browser, right?
The browser has been an app platform since Netscape developed plugins. That is my whole point.
The browser has been an app platform since Netscape developed plugins. That is my whole point.
But Netscape didn't create Java. The browser was not created to be an application runtime; commercial interests shoehorned the role onto it.
> But Netscape didn't create Java
So what? They didn't invent HTML either.
> The browser was not created to be an application runtime
It's been 35 years since HTML was invented, and 30 years since Netscape was released. There have been dozens - or maybe even hundreds - of browsers written in that time. So when you say, "the browser was not created to be an application runtime", really, I don't even know what that means. Which browser? Amaya? Arena? Lynx? Mosaic? Netscape? IE? IE6? Webkit? Blink?
"The browser" was created to be whatever their creators wanted it to be. Netscape, for better or worse, wanted it to be an application platform. And, to their credit, they were right.
So what? They didn't invent HTML either.
> The browser was not created to be an application runtime
It's been 35 years since HTML was invented, and 30 years since Netscape was released. There have been dozens - or maybe even hundreds - of browsers written in that time. So when you say, "the browser was not created to be an application runtime", really, I don't even know what that means. Which browser? Amaya? Arena? Lynx? Mosaic? Netscape? IE? IE6? Webkit? Blink?
"The browser" was created to be whatever their creators wanted it to be. Netscape, for better or worse, wanted it to be an application platform. And, to their credit, they were right.
> So what? They didn't invent HTML either.
Exactly. They fucked up something that someone else had thought up.
> when you say, "the browser was not created to be an application runtime", really, I don't even know what that means. Which browser?
Pretty much none of them, except maybe IE (WebKit and Blink are not browsers, they are rendering engines, btw). Some were thought for read-write capabilities in pages (Amaya and to a degree the original Netscape suite with their built-in editor), but that's basically it. Netscape pivoted this and that way, as scrappy startups are wont to do, following random partnerships or shipping their own suite, until they were acquired by AOL. Whatever they say, they really had no big design; they just threw the kitchen sink at something they thought would be cool. It just so happened that eventually Apple and Google figured that the JS/HTML coupling made for their best bet to break Microsoft's dominance in the application space, and started throwing engineers at it. Without that move, JS would still be the rollover trick-pony that it was in the early '00s, with the wonky inconsistent syntax and horrendous performance.
The one browser that was really thought of as a runtime was basically IE, with ActiveX and its deep embedding into Windows. That was a bad idea and it rightly ended like it did.
Exactly. They fucked up something that someone else had thought up.
> when you say, "the browser was not created to be an application runtime", really, I don't even know what that means. Which browser?
Pretty much none of them, except maybe IE (WebKit and Blink are not browsers, they are rendering engines, btw). Some were thought for read-write capabilities in pages (Amaya and to a degree the original Netscape suite with their built-in editor), but that's basically it. Netscape pivoted this and that way, as scrappy startups are wont to do, following random partnerships or shipping their own suite, until they were acquired by AOL. Whatever they say, they really had no big design; they just threw the kitchen sink at something they thought would be cool. It just so happened that eventually Apple and Google figured that the JS/HTML coupling made for their best bet to break Microsoft's dominance in the application space, and started throwing engineers at it. Without that move, JS would still be the rollover trick-pony that it was in the early '00s, with the wonky inconsistent syntax and horrendous performance.
The one browser that was really thought of as a runtime was basically IE, with ActiveX and its deep embedding into Windows. That was a bad idea and it rightly ended like it did.
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.
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.
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)
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)
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.
Besides that, I like it. Thanks for the links.
We will increase the delay.
Thank you for the feedback!
You can reach us anytime at [email protected]
Does not work at all for me.
Is this a commercial product?
Is this a commercial product?
What is it that does not work? You can also email us at [email protected]
• https://new.rt.ht (try starting fresh here)
If you cannot save your code, just save the URL which encodes the complete state down to the selected text ranges.
Saving/deployed to 275+ Cloudflare locations may not be available globally yet.
It is will be a free playground with commercial features, such as edge-deployed workers which can be developed in-editor:
• https://sw.rt.ht/? (in-editor)
• https://sw.rt.ht (edge-deployed)
• https://new.rt.ht (try starting fresh here)
If you cannot save your code, just save the URL which encodes the complete state down to the selected text ranges.
Saving/deployed to 275+ Cloudflare locations may not be available globally yet.
It is will be a free playground with commercial features, such as edge-deployed workers which can be developed in-editor:
• https://sw.rt.ht/? (in-editor)
• https://sw.rt.ht (edge-deployed)
> 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.
Does it matter? (Serious question) Not for a full website where it matters for duplication / caching / performance, but in this context - for the playground.
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.
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.
I do stuff like this regularly:
<div>…</div><script>document.currentScript.previousSibling.…</script>
Yeah I think I was doing something similar. The scripts can safely be executed as soon as the HTML/DOM is in there, no need to defer to the end.
> There is one little quirky js thing you can do to get the script element from inside the script.
Now you *have* to elaborate. And what's the problem it solves?
Now you *have* to elaborate. And what's the problem it solves?
I think it's just document.currentScript
I used it years ago because we had an XML based templating engine and some "components" needed to inject little scripts to add functionality. I could have given everything unique IDs but this was more fun. Forget what I did with it but I need to know where it was in the DOM or something.
I used it years ago because we had an XML based templating engine and some "components" needed to inject little scripts to add functionality. I could have given everything unique IDs but this was more fun. Forget what I did with it but I need to know where it was in the DOM or something.
Sometimes yes, sometimes no.
> 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.
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.
Agreed. Great job.
Yes cubed! Thank you.
just for the record MDN's site, hands down, has the best documentation ever made by any agent of the programming industry
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.
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.
Yet for some reason w3schools ranks higher in Google for many queries.
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.
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.
I was telling a junior to avoid w3schools and use MDN, but I couldn't really give him a reason besides "everyone seems to hate it". What's the rationale for all the shade thrown at w3schools?
w3schools is a for-profit company that survives on its schooling business. Its incentives are mis-aligned with mine: When I search for information on something web-dev related, I want it to be short & to the point. For w3schools, to maximize paid lesson uptake, it needs to only superficially explain what I want to know, enough to leave me confused and willing to pay for lessons.
That is even assuming w3schools has accurate information, which historically they did not, and there is no reason why they will not lapse in this regard in the future.
MDN has better aligned incentives on other hand, if I can find the information I need quickly, then I can developer faster and higher quality websites, which in turn in the aggregate will benefit the participants in MDN who are incentivized to increase their respective browser penetration (etc., I don't want to get into a whole discussion here).
At some point you come to a level where approximately 0% of the w3schools pages contain the information you need, but 100% of the MDN pages. So.. why have the overhead of w3schools results? Also, why develop bad habits early on?
That is even assuming w3schools has accurate information, which historically they did not, and there is no reason why they will not lapse in this regard in the future.
MDN has better aligned incentives on other hand, if I can find the information I need quickly, then I can developer faster and higher quality websites, which in turn in the aggregate will benefit the participants in MDN who are incentivized to increase their respective browser penetration (etc., I don't want to get into a whole discussion here).
At some point you come to a level where approximately 0% of the w3schools pages contain the information you need, but 100% of the MDN pages. So.. why have the overhead of w3schools results? Also, why develop bad habits early on?
I'd say w3schools is actually much better for beginners than MDN. If you learn HTML, CSS or JavaScript, MDN will often include too much unimportant information. (Similar to how Wikipedia math articles are often inscrutable for beginners because they are littered with lots of advanced low-importance information.) Additionally, w3schools has more easy "try it" examples which MDN consideres too trivial to bother with.
I agree though that MDN is much better than w3schools for non-beginners.
I agree though that MDN is much better than w3schools for non-beginners.
https://www.w3fools.com/:
> When W3Fools was launched in 2011, the state of documentation for developers was poor. This site documented many content errors and issues with the W3Schools website. The Mozilla Developer Network was around but it did not have much support at the time.
> Today, W3Schools has largely resolved these issues and addressed the majority of the undersigned developers' concerns. For many beginners, W3Schools has structured tutorials and playgrounds that offer a decent learning experience. Do keep in mind: a more complete education will certainly include MDN and other reputable resources.
And the archived version where you can get a flavor of the specific content complaints: https://web.archive.org/web/20110412103745/http://w3fools.co...
> When W3Fools was launched in 2011, the state of documentation for developers was poor. This site documented many content errors and issues with the W3Schools website. The Mozilla Developer Network was around but it did not have much support at the time.
> Today, W3Schools has largely resolved these issues and addressed the majority of the undersigned developers' concerns. For many beginners, W3Schools has structured tutorials and playgrounds that offer a decent learning experience. Do keep in mind: a more complete education will certainly include MDN and other reputable resources.
And the archived version where you can get a flavor of the specific content complaints: https://web.archive.org/web/20110412103745/http://w3fools.co...
Can also use a DDG bang: https://duckduckgo.com/bangs?q=mdn
Using !mdn takes you to a mediocre-at-best MDN search page, not a specific page. My experience is that you’ll get better results from just adding the “mdn” keyword to the query and jumping to the first result—that is, instead of, say, `mix-blend-mode !mdn` (which takes you to https://developer.mozilla.org/en-US/search?q=mix-blend-mode), `mix-blend-mode mdn !` (which takes you to https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-m...; the ! to skip the results page and go to the first match can be at the start or end of the entire query). This technique doesn’t guarantee you’ll end up on MDN, but for realistic queries you’re almost certain to.
Not the same, as I would then _only_ search MDN.
MDN does not know anything about the battle of waterloo:
https://developer.mozilla.org/en-US/search?q=battle+of+water...
And Wikipedia does not have any real API documentation of `requestAnimationFrame`
https://en.wikipedia.org/wiki/Special:Search?go=Go&search=re...
I want both of these to return sensible results for the bang-less search. This is the easiest for me and as a user of the search engine product, should also be what the search engine delivers me.
MDN does not know anything about the battle of waterloo:
https://developer.mozilla.org/en-US/search?q=battle+of+water...
And Wikipedia does not have any real API documentation of `requestAnimationFrame`
https://en.wikipedia.org/wiki/Special:Search?go=Go&search=re...
I want both of these to return sensible results for the bang-less search. This is the easiest for me and as a user of the search engine product, should also be what the search engine delivers me.
Any reason not to mention which search engine you use?
To put the focus on the principle of controlling your search engine results, rather than the specific tool (which is Kagi btw)
I'm not him but Kagi supports this functionality, and I make heavy use of it. Incredibly useful.
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.
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.
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.
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.
Thank you for sharing, feedback like this is a great to see :)
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.
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.
Then you haven't seen Rust's documentation yet.
https://doc.rust-lang.org/std/index.html
https://doc.rust-lang.org/std/index.html
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.
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.
You linked to the docs for the result type of `map`, not`map` itself. The method is here:
https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...
https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...
That MDN page has a lot of noise and is not straight to the point. I guess that may be a side effect of JS though.
While both of these docs are pretty good, as someone who normally much prefers API references to "how to" formats, the MDN's "how to" approach here is succinct & just enough to cover reasonable bases, while the Rust API ref list is a bit too terse by comparison (& the Read More click out is a bit annoying).
Where's the noise? I'm not seeing any.
I'm partial to Elixir's documentation myself: https://hexdocs.pm/ecto/Ecto.html
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/
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/
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.
With full appreciation of all the complexities and intricacies involved here, the state of these official documentation resources as they exist today isn't great.
Additionally, most initiatives aimed at improving the situation have only resulted in yet more overhead in the form of additional committees with each their own agendas and procedures, or the creation of another new deeply interconnected but otherwise completely separate sibling standard[0][1][3][4], fragmenting things even further.
I used to be quite heavily involved with some of the more meritful of those initiatives, but at some point realised that despite all the time and effort I was putting in, nothing really meaningful/impactful had been achieved or was even anywhere in sight, and it was also becoming too costly on a personal level. Guess that's my justification for having the right to post this rant :)
[0] https://infra.spec.whatwg.org/
[1] https://webidl.spec.whatwg.org/
[2] https://w3c.github.io/html-aam/
[4] https://w3c.github.io/html-aria/
Additionally, most initiatives aimed at improving the situation have only resulted in yet more overhead in the form of additional committees with each their own agendas and procedures, or the creation of another new deeply interconnected but otherwise completely separate sibling standard[0][1][3][4], fragmenting things even further.
I used to be quite heavily involved with some of the more meritful of those initiatives, but at some point realised that despite all the time and effort I was putting in, nothing really meaningful/impactful had been achieved or was even anywhere in sight, and it was also becoming too costly on a personal level. Guess that's my justification for having the right to post this rant :)
[0] https://infra.spec.whatwg.org/
[1] https://webidl.spec.whatwg.org/
[2] https://w3c.github.io/html-aam/
[4] https://w3c.github.io/html-aria/
Someone put it like this recently: the audience for specs is browser vendors, and the audience for MDN is web developers; ideally, you shouldn't have to go to the specs if MDN describes the features well enough to get your application running or your problem solved. MDN docs consider the practical aspect of how application developers will use features or why they should care, so there is a need to keep the content accessible in as many ways as possible.
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!
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!
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.
Especially considering they are facing an unusual hassle: browsers' compatibility (which is completely out of their control).
The quality of MDN gave me enough confidence to move away from frameworks and take matters into my own hands.
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.
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.
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.
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.
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.
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.
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.
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.
It's called find a new job and never look back.
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!
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.
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.
Here's the announcement blog post for some context: https://developer.mozilla.org/en-US/blog/introducing-the-mdn...
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
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
The AI Help feature looks super interesting, any plans to integrate it into the playground?
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
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
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.
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.
Except it gets mostly everything wrong, even very simple things that are on the page itself.
https://github.com/mdn/yari/issues/9208
https://github.com/mdn/yari/issues/9208
I'm really not sure how you can argue that "AI is great at explaining code snippets" while also acknowledging that it will just give you flat out wrong answers some times.
Either it's good at explaining and is right, or is bad at explaining and is wrong.
Applying the logic of it being "right most of the time" seems really bad for a tool applied to a reference documentation website.
Either it's good at explaining and is right, or is bad at explaining and is wrong.
Applying the logic of it being "right most of the time" seems really bad for a tool applied to a reference documentation website.
Sorry, if that wasn't clear but I think MDN is not only reference documentation. I agree, for the reference part the AI shouldn't do more than trying to point you to the right parts of the text. But for learning things, nice explanations, even if sometimes slightly off, can be a lot better to digest than reference documentation.
I'm not saying it's great yet, but there is potential for having something that can hand-wave away some details like a human would when explaining something to a beginner.
I'm not saying it's great yet, but there is potential for having something that can hand-wave away some details like a human would when explaining something to a beginner.
I liked that it is lightweight than codesandbox, stackblitz etc.Also, surprised that it has intellisense but it doesn't work for `console.log`.
It's something more like jsfiddle than a full-blown dev environment like codesandbox or stackblitz.
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.
Great catch, should be fixed with our nightly (UTC) deployment.
They have to solve the problems JSBin and like solved years ago all over again. Starting with infinite loops ;)
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
[1] https://www.jsplayground.dev [2] https://babeljs.io
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
Can I has a vim mode please ? I am not returning back to using arrows to move around text
"install" the web page. That opens up more keyboard shortcuts.
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.
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.
Nice to see this from MDN. My go to playground has been jsfiddle, will start using this.
Any chance emmet and autocompletion can be added for the editor?
shows why simple works
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.