I would expect the performance to be worse, given that it does something much more complex. But it’s still great to have it.
GetElementById vs. QuerySelector
51–60 of 100 posts
Re: GetElementById vs. QuerySelector
#52I'm getting getElementById is 2x to 4x faster than querySelector depending on the browser
https://jsbenchit.org/?src=25e097f939f76b559b2515430fb5e459
I'm a little surprised. Sure i'd expected getElementById to be faster but honestly I'd have expected browser implementation of querySelector to do a relatively trivial up front check, is the selector a simple id, if so, call getElementById. I suppose that adds overheads to all queries, but that's true of many types of "best case" optimizations. (in the best case it's faster but adds some overhead for any non-best case)
Still, I don't care about this level of optimization. I'll just contuinue to use querySelector everywhere because it's more flexable. No code I've ever written looks up so many elements in a single interaction that this micro optimization would ever matter to me.
Re: GetElementById vs. QuerySelector
#53Edit: 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…
Glad to hear that Javascript is such a simple language and only experts should use things like C++.
Re: GetElementById vs. QuerySelector
#54Related: 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…
> one of my favourite
one of? you have tricks better than this? this is so fucking spicy holy cow. how did i not know this? excuse me while i add this to all my future code for no good reason :).
Re: GetElementById vs. QuerySelector
#55Was halfway expecting some counterintuitive result like that infamous "JSON.parse() is faster than an actual JSON literal" meme a while ago.
Somewhat relieving the results here follow the common-sense expectation. (I.e. getElementById is faster than querySelector)
Re: GetElementById vs. QuerySelector
#56Earlier quoted context omitted.
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…
Glad to hear that Javascript is such a simple language and only experts should use things like C++.
This is an API issue (DOM), not a language one.
Re: GetElementById vs. QuerySelector
#57Interesting, but, if you are handling anywhere near 100,000 elements you should probably be maintaining references rather than querying the DOM each time.
Re: GetElementById vs. QuerySelector
#58I'm getting getElementById is 2x to 4x faster than querySelector depending on the browser https://jsbenchit.org/?src=25e097f939f76b559b2515430fb5e459 I'm a little surprised. Sure i'd expected getElementById to be faster but honestly I'd have expected browser implementation of querySelector to do a relatively trivial up front check, is the selector a simple id, if so, call getElementById. I suppose that adds overheads…
> No code I've ever written looks up so many elements in a single interaction that this micro optimization would ever matter to me.
Exactly. This is the type of nano-optimization that is pretty common to see in e.g. SO answers. Sure, selecting _a hundred thousand_ items in a loop might be some milliseconds faster, but so what? How often are you selecting more than a few at most?
Re: GetElementById vs. QuerySelector
#59Earlier quoted context omitted.
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 :)
also with querySelector you can use queries like
> ids.map(id=> `#test${id}`).join(" , ")
or
> `[id^="test"]`
to get all elements that have an id that starts with test
Re: GetElementById vs. QuerySelector
#60Earlier quoted context omitted.
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