You are misreading the documentation. There's no such distinction as live node vs. static node in that sense. There's only a distinction between a live node list and a static node list. This is a difference between getElementsByClassName("foo") and querySelectorAll(".foo"), but not between getElementById("foo") and querySelector("#foo").

The difference is whether membership changes in the collection are reflected immediately. Changes to the nodes themselves are reflected as usual either way, and node references do not spookily invalidate or repoint themselves.

spookily?

Its a reference to Einstein's spooky [action at a distance](https://en.wikipedia.org/wiki/Action_at_a_distance)

It's not part of javascript, it's part of the DOM API, and yes, that makes a difference. That's like calling C++ bad because you don't like boost, or calling python bad because you don't like django. (I am not saying tho that there isn't plenty to criticize in javascript itself).

The DOM API is not javascript specific. The API surface is defined in terms of WebIDL (Web Interface definition language). While it is most commonly found in browsers and therefore javascript, it is not specific to browsers or javascript. Browsers themselves ship various javascript environments that do not even include the DOM API at all (WebWorkers aka threads, ServiceWorkers, PAC all give you an environment without a DOM). nodejs doesn't come with a DOM (tho there is an implementation available in jsdom). There is nothing really preventing you from looking at the DOM spec and writing your own DOM API implementation for your preferred language. In fact Microsoft and Google used to do that for their in-browser support of vbscript and dart respectively, python ships with xml.dom (implementing an older version of the spec), java ships with org.w3c.dom (implementing an older version of the spec). There is a C# implementation in the AngleSharp library, somebody wrote a go implementation, and so on.

So tell me, how would the invalidation work if the API were written in a language like Rust?

You've just listed a bunch of GCed languages and told me it's due to the API not the language. GC lets you be sloppy with resource initialization/cleanup though, and having GC doesn't magically fix when the external objects you interact with go in and out of scope.

So what I'm arguing above is that GCed languages are actually just as hard as manual memory managed languages the moment you need to interact with the real world... be it UI elements, file handles, network sockets, or whatever. Memory isn't the only resource that needs management, and languages that have idiomatic resource management are actually good at this kind of thing.

This is an API issue (DOM), not a language one.

No, it's a language issue. The language doesn't let you specify that things cannot go out of scope 'spookily', so it is ambiguous and you have to trust things like documentation. Just like it's easy to make memory management issues in C, this is the kind of thing that's easy to get wrong in JS.

Deflecting to semantics or categorization isn't a defense.

My point it that it is a defined behaviour of the DOM API which is generally implemented in C++ and exposed to Javascript environment. It behave exactly the same way if you use bindings for any other language. It's not an ECMAScript defined feature.

You can also implement exactly this behaviour in any language so how is this then a Javascript language issue?

Similarly, C is crappy because operating system APIs are crappy.

This is nonsense for querySelector and getElementById. They both query the current state of the DOM and return an Element or null. Variables can’t get deleted under you in JavaScript, so if you have a reference to a node that you remove from the DOM, it’s still the same node until you release all references and it gets garbage collected, or you put it back in the DOM.

What you’re talking about is only applicable or relevant for the methods that return collections. querySelectorAll returns a static NodeList, getElementsByName/getElementsByTagName/getElementsByClassName return live NodeLists or HTMLCollections.

> querySelector return a static node while getElementById returns a live node. If the element returned by getElementById is deleted in the DOM, the variable becomes unavailable while for querySelector you get a snapshot of the node that lives on.

I'm mostly sure that this is not true: https://imgur.com/a/XaS3b0W

It makes sense that that would be the case. You still have a reference in scope to the element, so the GC leaves it alone. I could see the described behavior as a bug in maybe an older engine, but so far as I can recall I've never run into it in practice.

The responses to this are a fantastic example of Cunningham’s Law at work. Thank you!

Yeah, I surprised to even see those two terms on an article on HN (who uses getElementById or querySelectors nowadays right?) but I was even more surprised by the number of comments it gathered (which are of course unrelated to the original article)

I use getElementById pretty often

What else would you use?

I use them all the time.

I do as well. I often prototype behavior in Vanilla ES6+ JavaScript.

That’s incorrect. Maybe you’re thinking of querySelectorAll, which returns a static list, compared to getElementsByTagName and getElementsByClassName, which return live ones?

I wonder why we need all these different collections. Makes the DOM feel hacked together by lots of totally different people not communicating (?) There's probably a reason, though.

That's because it was hacked together by lots of totally different people not communicating. Over a couple of decades, no less.

Exactly. Once upon a time the powers that were figured a live node list would be cool, so they did that. Many moons later, the new powers that were decided that while a live node list looks cool, it contains too much magic pixie dust which may cause allergies in a lot of people (symptoms include frantically screaming at your screen about why this stuff doesn't work like you expect it to work). But they couldn't just change existing stuff or risk breaking the web. But they could avoid it for new stuff, and so they did that.

For reference: https://xkcd.com/927/

What an awful design. Why would it differ like that? No doubt some legacy baggage that was later turned into a justification.

These APIs didn’t all come out the same time, so they weren’t designed to differ.

Instead they decided against doing live node lists in future but couldn’t change how the older methods work as that would break websites. In the world of DOM/JS you can’t really make breaking changes.

https://humanwhocodes.com/blog/2010/09/28/why-is-getelements... Has more context

I'd actually expect the opposite just from the names. I'd expect a selector to select a "live" node, and getElement to get a static one.

Whoa! As someone who likes to think they know a thing or two about vanilla JS, I did not know this. This is pretty dang important.