5 ms·

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

by rudian 5y ago

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.

lhorie 5y ago
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/now https://developer.mozilla.org/en-US/docs/Web/API/Performance...
- rudian 5y ago
  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.
  - lhorie 5y ago
    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
- leeoniya 5y ago
  yep. and please dont query the dom 100k times, or in a loop :)
  - afiori 5y ago
    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
    - jfrunyon 5y ago
      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.
      - afiori 5y ago
        well at that point it would be wise not to use ids for queries, but the logic remains the same.
jaynetics 5y ago
> This is the sort of micro optimization you should not concern yourself with. Not as an app dev, but if you transpile your code anyway, a transpiler plugin that does this and similar optimizations could be neat.
- rudian 5y ago
  A few minification transforms actually kind of speed code up. If Babel hadn’t turned into a hydra this kind of transforms would have been right up its alley.
iKevinShah 5y ago
> 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.
- olavgg 5y ago
  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.
  - rudian 5y ago
    Yeah but they’re not necessary for selection. Label elements actually need an input with ID to function. The other useful use for IDs is for deep-links in articles. But then again that doesn’t mean the id should be used for selection (in JS nor CSS) as it’s probably easier to target many elements with a class, should they ever co-exist. This is basically what you end up with if you build components anyway (even without specific frameworks)
    - iKevinShah 5y ago
      > Yeah but they’re not necessary for selection wouldn't it be easier to select an item with ID than select one with a class name and then iterate over to find which one you want. I am talking about items which exist only once. I am still not clear on why not to use IDs in a page in your opinion.
      - throwanem 5y ago
        In terms of convenience, there's no meaningful difference between querySelector and getElementById. Given <html> <body> <div id="example" class="example" /> </body> </html> we can do any of document.querySelector('.example'); document.querySelector('#example'); document.getElementById('example'); and get the same result, namely the Element object representing that div. When there are multiple matching elements on the page, results differ. From document.querySelector() you get back "the first Element within the document that matches the specified selector, or group of selectors" [1], and the spec defines the search for "first" as depth-first. [2] [3] Meanwhile, the docs for document.getElementById() [4] mention that "element IDs are required to be unique if specified", and this too we find borne out in the relevant spec. [5] If there is a specified way for DOM implementations to behave when element IDs aren't unique in the document, I haven't yet been able to find it. In any case, given the liberality with which the docs are peppered with warnings and reminders that IDs must be unique, violating that invariant takes us outside the expectation of implementation guarantees, so it's not all that easy to complain if it behaves differently across browsers or otherwise isn't predictable. So, for elements that exist only once, it's as easy to select them by class as by ID, and using a class has the additional benefit that it's one fewer refactor if you do decide to use that element more than once - if you use ID to begin with, you have to change that when you reuse the element. This is also not a meaningful difference in convenience, I think. [1] https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector https://developer.mozilla.org/en-US/docs/Web/API/Document/qu... [2] https://drafts.csswg.org/selectors-4/#match-a-selector-against-a-tree https://drafts.csswg.org/selectors-4/#match-a-selector-again... [3] https://dom.spec.whatwg.org/#concept-shadow-including-tree-order https://dom.spec.whatwg.org/#concept-shadow-including-tree-o... [4] https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById https://developer.mozilla.org/en-US/docs/Web/API/Document/ge... [5] https://html.spec.whatwg.org/multipage/dom.html#global-attributes https://html.spec.whatwg.org/multipage/dom.html#global-attri...

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

by rudian 5y ago

lhorie 5y ago

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/now https://developer.mozilla.org/en-US/docs/Web/API/Performance...

rudian 5y ago
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.
- lhorie 5y ago
  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
leeoniya 5y ago
yep. and please dont query the dom 100k times, or in a loop :)
- afiori 5y ago
  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
  - jfrunyon 5y ago
    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.
    - afiori 5y ago
      well at that point it would be wise not to use ids for queries, but the logic remains the same.

jaynetics 5y ago

> This is the sort of micro optimization you should not concern yourself with. Not as an app dev, but if you transpile your code anyway, a transpiler plugin that does this and similar optimizations could be neat.

rudian 5y ago
A few minification transforms actually kind of speed code up. If Babel hadn’t turned into a hydra this kind of transforms would have been right up its alley.

iKevinShah 5y ago

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

olavgg 5y ago
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.
- rudian 5y ago
  Yeah but they’re not necessary for selection. Label elements actually need an input with ID to function. The other useful use for IDs is for deep-links in articles. But then again that doesn’t mean the id should be used for selection (in JS nor CSS) as it’s probably easier to target many elements with a class, should they ever co-exist. This is basically what you end up with if you build components anyway (even without specific frameworks)
  - iKevinShah 5y ago
    > Yeah but they’re not necessary for selection wouldn't it be easier to select an item with ID than select one with a class name and then iterate over to find which one you want. I am talking about items which exist only once. I am still not clear on why not to use IDs in a page in your opinion.
    - throwanem 5y ago
      In terms of convenience, there's no meaningful difference between querySelector and getElementById. Given <html> <body> <div id="example" class="example" /> </body> </html> we can do any of document.querySelector('.example'); document.querySelector('#example'); document.getElementById('example'); and get the same result, namely the Element object representing that div. When there are multiple matching elements on the page, results differ. From document.querySelector() you get back "the first Element within the document that matches the specified selector, or group of selectors" [1], and the spec defines the search for "first" as depth-first. [2] [3] Meanwhile, the docs for document.getElementById() [4] mention that "element IDs are required to be unique if specified", and this too we find borne out in the relevant spec. [5] If there is a specified way for DOM implementations to behave when element IDs aren't unique in the document, I haven't yet been able to find it. In any case, given the liberality with which the docs are peppered with warnings and reminders that IDs must be unique, violating that invariant takes us outside the expectation of implementation guarantees, so it's not all that easy to complain if it behaves differently across browsers or otherwise isn't predictable. So, for elements that exist only once, it's as easy to select them by class as by ID, and using a class has the additional benefit that it's one fewer refactor if you do decide to use that element more than once - if you use ID to begin with, you have to change that when you reuse the element. This is also not a meaningful difference in convenience, I think. [1] https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector https://developer.mozilla.org/en-US/docs/Web/API/Document/qu... [2] https://drafts.csswg.org/selectors-4/#match-a-selector-against-a-tree https://drafts.csswg.org/selectors-4/#match-a-selector-again... [3] https://dom.spec.whatwg.org/#concept-shadow-including-tree-order https://dom.spec.whatwg.org/#concept-shadow-including-tree-o... [4] https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById https://developer.mozilla.org/en-US/docs/Web/API/Document/ge... [5] https://html.spec.whatwg.org/multipage/dom.html#global-attributes https://html.spec.whatwg.org/multipage/dom.html#global-attri...