[deleted]
GetElementById vs. QuerySelector
21–30 of 100 posts
Re: GetElementById vs. QuerySelector
#22In 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')`.
Re: GetElementById vs. QuerySelector
#23Edit: 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 imm…
spookily?
Re: GetElementById vs. QuerySelector
#24Please 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.
OP is explaining their methodology poorly. The 62ms number is the time it takes to run the call 100,000 times, in a loop, with a string interpolation. And measurement is done by taking the delta of two performance.now() calls, which are known to be precise to only about 1ms for spectre mitigation[0].
FWIW, JS old timers have known querySelector is slower than getElementById since querySelector became a thing.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Performance...
Re: GetElementById vs. QuerySelector
#25In 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')`.
You could avoid that quite easily by using IDs that don't need escaping though.
That said, the fact escaping is necessary could point to part of the reason why querySelector is slower. There's obviously some additional parsing necessary just to work out what the developer is requesting. If you don't need to spend that CPU time then it's certainly better not to.
Re: GetElementById vs. QuerySelector
#26Why is Chrome so slow with this? Does anyone know
Google's greed /s
Re: GetElementById vs. QuerySelector
#27Please 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.
OP is explaining their methodology poorly. The 62ms number is the time it takes to run the call 100,000 times, in a loop, with a string interpolation. And measurement is done by taking the delta of two performance.now() calls, which are known to be precise to only about 1ms for spectre mitigation[0]. FWIW, JS old timers have known querySelector is slower than getElementById since querySelector became a thing. [0] htt…
I know, that's why it's misleading and it should not be considered. A quick reader will think that "using getElementById will save me 32ms", but it'd be off by several orders of magnitude.
Re: GetElementById vs. QuerySelector
#28[deleted]
Re: GetElementById vs. QuerySelector
#29Related: 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…
[deleted]
Re: GetElementById vs. QuerySelector
#30Please 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.
OP is explaining their methodology poorly. The 62ms number is the time it takes to run the call 100,000 times, in a loop, with a string interpolation. And measurement is done by taking the delta of two performance.now() calls, which are known to be precise to only about 1ms for spectre mitigation[0]. FWIW, JS old timers have known querySelector is slower than getElementById since querySelector became a thing. [0] htt…
yep. and please dont query the dom 100k times, or in a loop :)