[rudian]

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]

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

[rudian]

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]

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]

yep. and please dont query the dom 100k times, or in a loop :)

[afiori]

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]

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]

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

[iKevinShah]

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

[solarkraft]

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.

[Vinnl]

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.

[jfrunyon]

They should have high specificity - and it should be hard to override them with other selectors - because they are specific. They can only select at most one element. Why would you want to override it? Then you'd have cruft (i.e. a bug in waiting) in the obvious place to look in the future.

[robocat]

> They can only select at most one element.

Incorrect. An ID can be repeated on as many elements in a page as you like. It is only convention that makes an id “unique”. I am not suggesting you do it, since here be dragons e.g. I just got a stack trace in the console of jsbin.com on Mobile Safari when I was testing with two elements with the same id — it breaks developer’s assumptions.

[jfrunyon]

Incorrect. getElementById returns a single element, regardless of how many elements you put with the same id; furthermore, having multiple elements with the same id is a violation of the relevant standards, so browsers may do whatever they want at that point (including ignore the repeated id on ALL elements, ignoring it on SOME elements, or honoring it on all elements). And in fact various browsers at various times have done all 3 of those things. Even today both Chrome and Firefox do two of those things depending on how you look at it (getElementById returns a single element, but CSS selectors apply to all elements with the ID).

It is only convention that gives anything meaning. HTML attributes are given meaning by convention. The words I'm writing right now are given meaning by convention. That implies abolutely nothing about the meaning or validity thereof.

> the id attribute value must be unique amongst all the IDs in the element's tree ... The id attribute specifies its element's unique identifier (ID).

https://html.spec.whatwg.org/multipage/dom.html#global-attri...

[robocat]

It is uncommon knowledge that id’s do not have to be unique.

document.querySelectorAll('#test').length will return 2 if there are two elements on the page with the same id=test attribute. I personally avoid using that ‘feature’ because it would confuse many people, but it is important to know if you run into certain bugs in code.

[kall]

When using a component framework, I consider components that can only be put on the page once a bad practice. Sure you probably only have the user menu on the page once, but it shouldn‘t rely on that. Not the case in a storybook for example. If I use IDs, to associate aria labels etc, they are mostly randomized.

[olavgg]

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]

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]

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

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

[2] https://drafts.csswg.org/selectors-4/#match-a-selector-again...

[3] https://dom.spec.whatwg.org/#concept-shadow-including-tree-o...

[4] https://developer.mozilla.org/en-US/docs/Web/API/Document/ge...

[5] https://html.spec.whatwg.org/multipage/dom.html#global-attri...

[iKevinShah]

That is exactly how use it too. For unique items which 100% will be once on a given page. CSS can be applied too however re-usability of css styles for a given component no more is possible but that is an agreed upon side effect.

[jaynetics]

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

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.