GetElementById vs. QuerySelector
blog.wesleyac.com
GetElementById vs. QuerySelector
1–10 of 100 posts
Re: GetElementById vs. QuerySelector
#2I love seeing little "science" experiments like these. Definitely interesting, ty article author.
Re: GetElementById vs. QuerySelector
#3Edit: 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...
Re: GetElementById vs. QuerySelector
#4Edit: 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 w…
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.
Re: GetElementById vs. QuerySelector
#5Edit: 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 w…
What an awful design. Why would it differ like that? No doubt some legacy baggage that was later turned into a justification.
Re: GetElementById vs. QuerySelector
#6Edit: 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 w…
What an awful design. Why would it differ like that? No doubt some legacy baggage that was later turned into a justification.
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.
Re: GetElementById vs. QuerySelector
#7Edit: 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 w…
> 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
Re: GetElementById vs. QuerySelector
#8Edit: 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 w…
That’s incorrect. Maybe you’re thinking of querySelectorAll, which returns a static list, compared to getElementsByTagName and getElementsByClassName, which return live ones?
Re: GetElementById vs. QuerySelector
#9Edit: 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 w…
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.
Re: GetElementById vs. QuerySelector
#10Edit: 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 w…
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.