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.
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
> 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.
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.
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.
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.
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.
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).
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.
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.
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)
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.
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.
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.
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.
They are different, currently no Deno registries have dynamic version resolution (no greater than operator). Once you have locked in on a version you are in it for good unless you change it manually
However if the argument is: updating libraries break stuff, that is gonna happen every time in every language. There is no guarantee the next version will just work as the last one did
- too many street names make for a noisy/busy/ugly map, and we all know maps must be beautiful and nothing else
- streets don’t pay for ads, businesses do, so between the two they prefer showing the latter.
Technically now you can tap anywhere on the map once to place a pin and get more info; In practice tapping in Google Maps has become horrendous, it never does what you expect. One such example is tapping on a business near a “walkable area”: you can’t. The area will always focus instead, even if painted behind the business.
I remember some browser blocking that at some point, but I still occasionally see it. I can’t believe there’s no way to “go back to the previous website” in most browsers. Safari iOS for example just clips the history so you can’t even hold the back button and scroll up if there are dozens of entries.
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.