Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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...



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.


That sounds like a pit of success, though. The gain just isn't that significant. IMHO, misleading would be if querySelector was faster under normal circumstances but shown to be slower through bad benchmarking


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


Thus opening up a whole swarm of potential bugs, you should probably just use a class if you need to reference a list of elements when possible.


well at that point it would be wise not to use ids for queries, but the logic remains the same.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: