This site is a real gem. Clean, simple, and minus the excessive complexity and obfuscation caused by frameworks. Doing & Learning things in plain JS we can learn fundamentals.
The MDN docs are from my experience the best browser frontend reference available.
This site however covers a different need: guide/howto oriented documentation, which is often what you want.
> Doing & Learning things in plain JS we can learn fundamentals.
To this I have to add that I often do write plain JS supported by only a few, small libraries such as is.js, axios, json-schema and so on. This is regarding small to medium sized projects and/or features.
This can easily save time, setup and mental energy, as long as one follows a consistent, simple structure. And on top of that, the fewer dependencies you have, the less friction.
But it also means that one has to have a bit of a deeper knowledge of the available frameworks and tools, which can manage complexity with growing features, because you add them incrementally and only when needed and so on.
MDN is great as if you're reading the manual with all the details and etc.
But like a lot of raw manuals sometimes you read it and wonder "Wait.. why would I want to do this again? Does this even do the thing I started looking for?"
Some of their examples have actually evolved to be a bit more akin to more usage based rather than raw specs.
I do appreciate the other sites that are more "You want to..." as a complement to MDN and such.
Honestly, while axios is nice to have on the server side, the websocket API in the browser is very simple to use. Which IMO is a consistent theme with modern browser APIs.
Agreed: on our current front end project at work I’m having a lot of fun teaching the team the amazing browser APIs that subsume the need for a lot of the third party dependencies we used to reach for
In this project, simple: we don't have to. Despite being a decade old application, it was entirely AJAX-driven and front-end focused even back in 2010, and IE support was dropped entirely a few years ago by the business. Works in Edge just fine, as to be expected
Agreed.
But the reason I asked because I am assuming they are making changes to a long-standing project that previously relied on third-party libraries (for browser compat?). I'm interested in that specific situation, not all projects in general.
Firstly, it doesn't tell the reader that every method of selecting elements listed is available on both a Document and an Element. document.getElementsByClassName selects everything in the page with that class name. Element.getElementsByClassName selects every child of an element with that class name. If you're wrangling a huge page using one is better than the other. Chaining calls is really useful eg document.getElementById('users').getElementsByClassName('admin').[1]
"Select an element by given ID" using getElementById() does select a single element on the page with that ID, which is right, but browsers don't enforce ID uniqueness so you're only getting the first element with that ID. That's a very common gotcha for devs who are new to this. (React would tell you if you've not got a unique key.)
.querySelectorAll() does not return a list of elements. It returns a NodeList, which is different to the HTMLCollection that the other methods return. For a start, NodeLists aren't iterable in the same way as HTMLCollections. You can use forEach but you can't use map. That's going to throw a lot of devs a curve ball.
Worst of all though, it doesn't mention .querySelector() for picking individual elements. Why would you miss that out?
[1] The page that does talk about selecting children (https://htmldom.dev/select-the-children-of-an-element) of an element suggests using an element's childNode array. That's horrible. There could be all manner of strange things in there. Just use an element.querySelector() call.
Just about everything on the Element node type is available directly on the Document. The document is actually a node type in the DOM. In JavaScript the DOM methods are populated on the global objects Element and Document and that is visible in the browser console with:
Document.prototype
You can see that the prototypes are almost but not exactly identical and both inherit from the global Node object. The page could have dived into that level of detail, but I think that largely misses the point. Most JavaScript developers are irrationally scared to death of the DOM and that page is trying to be a friendly low friction reference. If somebody were really looking for that level of granularity they could go to MDN or the DOM spec.
> but browsers don't enforce ID uniqueness
Actually, the browsers do. This isn't a browser shortcoming. It is an HTML shortcoming. If the code were parsed as XML the browser would point to the location of this violation.
> .querySelectorAll() does not return a list of elements. It returns a NodeList
Same thing. Node lists are iterable lists but are not a form of Array where the only practical difference is that a node list does not have the Array.prototype methods.
> The page that does talk about selecting children (https://htmldom.dev/select-the-children-of-an-element) of an element suggests using an element's childNode array. That's horrible. There could be all manner of strange things in there. Just use an element.querySelector() call.
Suggesting reliance on the convenience of the querySelector method is bad advise, especially from a learning and reference perspective. The querySelector method executes thousands of times slower than the other more specific methods because it requires a parse step. Also I see no danger of using the childNodes property. Simply don't make the blanket assumption that everything in the DOM is limited to element and text node types.
>.querySelectorAll() does not return a list of elements. It returns a NodeList, which is different to the HTMLCollection that the other methods return. For a start, NodeLists aren't iterable in the same way as HTMLCollections. You can use forEach but you can't use map. That's going to throw a lot of devs a curve ball.
querySelectorAll does return a list of elements. While technically a NodeList, you can't select non-element nodes with selectors which is why querySelectorAll never returns such.
Further, neither NodeList nor HTMLCollection implement methods like map, but both are quite iterable and in a similar fashion (by converting them to Arrays or using Array methods with them, like with other Array-like objects which JavaScript is full of). But if anything, NodeList is a "more" iterable type than HTMLCollection, as it does implement forEach itself, too.
I would certainly not recommend using querySelector for accessing an elements first child node or child element.
Too bad this site doesn't remember your scroll position when you go to a page and hit the back button. For a site promoting vanilla Javascript, it didn't really need to be built with React.
I love the idea, but the very first example on there ("How to add a class to an element") comes with the disclaimer "isn't supported in IE 11". Everyone likes to support only modern browsers, but completely dropping support for IE is unlikely to be acceptable for most users.
For my own sites I conditionally include a shim for IE users so I can use vanilla JS and only IE is bothered by the longer load time, using <!--[if lte IE 10]> ... <![endif]-->
