Live data from Hacker News

GetElementById vs. QuerySelector

blog.wesleyac.com

71–80 of 100 posts

Re: GetElementById vs. QuerySelector

#71
post #47

Earlier quoted context omitted.

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.

Re: GetElementById vs. QuerySelector

#72
post #59

Earlier quoted context omitted.

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.

Re: GetElementById vs. QuerySelector

#73
post #19

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.

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

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.

Re: GetElementById vs. QuerySelector

#74
post #41

Earlier quoted context omitted.

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

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.

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)

Re: GetElementById vs. QuerySelector

#75
post #19

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.

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

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.

Re: GetElementById vs. QuerySelector

#78
post #59

Earlier quoted context omitted.

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.

Re: GetElementById vs. QuerySelector

#79
post #64

Related: 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…

I would seriously not recommend doing this, because it's terrible at communicating intent. Yes, it works, but someone else (if you're lucky) or you will be staring at a variable that seems to have come out of nowhere trying to figure out what's going on sooner or later. Especially if the HTML id inadvertently got changed without changing the variable in kind

The spec appropriately points out that this is a fragile technique.

Also to avoid any doubt: if something’s called a golfing trick, you almost certainly shouldn’t use it on normal code.

I confess I use this technique on every page on my website, in my carefully-golfed light/dark mode switcher. (https://chrismorgan.info/blog/dark-theme-implementation/ has a slightly-expanded version of it, and uses a more sensible document.querySelector instead.)

Post reply on HN