MDN Playground

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

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.

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.

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.

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.

Does not work at all for me.

Is this a commercial product?

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.

Sometimes yes, sometimes no.

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

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

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.

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.

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.

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

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.

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!

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.

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.

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.