Live data from Hacker News

GetElementById vs. QuerySelector

blog.wesleyac.com

41–50 of 100 posts

Re: GetElementById vs. QuerySelector

#41
post #19

Please don't listen to this, it's misleading. querySelector *does not* take 62ms to run. Both of them take 0.01ms at most, try it yourself. This is the sort of micro optimization you should not concern yourself with. How often do you need to select unique elements by ID? Don't use IDs in the first place. This is akin to using `i--` in loops to "speed up your code" — we're past that.

> How often do you need to select unique elements by ID? Don't use IDs in the first place. wait a minute, does everyone NOT use IDs for unique elements on page (not each element)? I mean I am genuinely interested in knowing why not to use IDs. There are unique elements which need to be selected on a page like #logout or something.

I use id on unique elements on a page all the time. It can be a form, it can be a button and so on.

Re: GetElementById vs. QuerySelector

#42

Related: one of my favourite code golfing tricks is named access on the Window object https://html.spec.whatwg.org/multipage/window-object.html#na... >: document.getElementById("result").textContent = "Why do it this way—"; document.querySelector("result").textContent = "—or even this way—"; result.textContent = "—when you can do it this way?"; Edit: adding another similar test to this page, window[`test${i}`] is tak…

Bug fix: document.querySelector("#result")...

querySelector needs the '#' in this case.

Re: GetElementById vs. QuerySelector

#43
post #11

In the worst case > around 44ms and 206ms so around 162ms difference per 100,000 elements. This doesn't concern most of us for anything less than 1,000 elements (1.62ms). I use querySelector more often simply for aesthetics (consistent with other calls and qsAll).

I would prefer getElementById regardless of its performance because you may need escaping for CSS selectors, for example `getElementById('comment:1234')` vs. `querySelector('#comment\\:1234')`.

This is my subjective opinion, but I think getElementById makes the code easier to understand when you scan the code. Even if the query selector is simple, it still requires you to read the query to understand it's just a simple lookup by id

Re: GetElementById vs. QuerySelector

#44

I’m surprised by the apparent magnitude of the difference between Firefox and Chrome. On my laptop I’m getting results roughly twice as fast as reported in the article, but still fairly similar ratios all round: Firefox 96 (Nightly): document.getElementById 2–4ms avg 3ms, document.querySelector 25–27ms avg 27ms. Chromium 96 (stable): document.getElementById 11–37ms avg 19ms, document.querySelector 86–155ms avg 101ms.…

As mentioned elsewhere, this is probably not testing what it thinks it is. The benchmark is doing a bunch of weird things, using timers that are not very precise, throwing away the first results, using template literals, etc. The results should be taken with a grain of salt.

Re: GetElementById vs. QuerySelector

#45
post #19

Please don't listen to this, it's misleading. querySelector *does not* take 62ms to run. Both of them take 0.01ms at most, try it yourself. This is the sort of micro optimization you should not concern yourself with. How often do you need to select unique elements by ID? Don't use IDs in the first place. This is akin to using `i--` in loops to "speed up your code" — we're past that.

> How often do you need to select unique elements by ID? Don't use IDs in the first place. wait a minute, does everyone NOT use IDs for unique elements on page (not each element)? I mean I am genuinely interested in knowing why not to use IDs. There are unique elements which need to be selected on a page like #logout or something.

It’s a common CSS wisdom to use ids very sparingly because there’s always a chance you may want to have the same element on the page multiple times.

There are some scenarios in which this is the case you may not expect right away, sometimes you need to duplicate elements for responsivity, for example.

Re: GetElementById vs. QuerySelector

#46
post #40
post #32

Earlier quoted context omitted.

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 them all the time.

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

Re: GetElementById vs. QuerySelector

#47

Earlier quoted context omitted.

> How often do you need to select unique elements by ID? Don't use IDs in the first place. wait a minute, does everyone NOT use IDs for unique elements on page (not each element)? I mean I am genuinely interested in knowing why not to use IDs. There are unique elements which need to be selected on a page like #logout or something.

It’s a common CSS wisdom to use ids very sparingly because there’s always a chance you may want to have the same element on the page multiple times. There are some scenarios in which this is the case you may not expect right away, sometimes you need to duplicate elements for responsivity, for example.

I think for CSS the reason is mostly that IDs have very high specificity, so styling you apply there is very hard to override elsewhere in your stylesheet.

However, that just means that you will probably generally want to avoid using IDs in your selectors - not to avoid using them altogether, or in JavaScript.

Re: GetElementById vs. QuerySelector

#48

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

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

Re: GetElementById vs. QuerySelector

#49
post #8

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

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.

Re: GetElementById vs. QuerySelector

#50

Related: one of my favourite code golfing tricks is named access on the Window object https://html.spec.whatwg.org/multipage/window-object.html#na... >: document.getElementById("result").textContent = "Why do it this way—"; document.querySelector("result").textContent = "—or even this way—"; result.textContent = "—when you can do it this way?"; Edit: adding another similar test to this page, window[`test${i}`] is tak…

Woah, no way. Although I could see this being abused, it's amazing that this even works.

It has been abused to allow remote code execution in LastPass, a password manager.

https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

Post reply on HN