[simlevesque]

Edit: seems like I'm wrong.

They are both completely different and almost no one mentions how they differ in these comparison blog articles.

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.

If you use both of them the same way or don't know the difference, you are gonna have a bad time.

https://developer.mozilla.org/en-US/docs/Web/API/Document_ob...

[anderskaseorg]

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.

[kasajian]

spookily?

[JoelEinbinder]

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

[chrismorgan]

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.

[mysecretaccount]

> 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

[throwanem]

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.

[LeonB]

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

[rudasn]

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)

[ligerzer0]

I use getElementById pretty often

[nonima]

What else would you use?

[olavgg]

I use them all the time.

[bredren]

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

[minitech]

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

[tentacleuno]

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.

[jfrunyon]

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

[rndgermandude]

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.

[joshspankit]

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

[sillysaurusx]

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

[jayflux]

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

[Ozzie_osman]

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.

[sodapopcan]

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.