> > I'm not a front end dev

> But I am.

So am I, and I disagree with you.

Here's an actual benchmark that you can run[1] (why did you not share an actual benchmark?). I get, on my old and slow Android, 500k ops/sec for querySelector.

At 60fps, that allows you to do ~8000 selections per frame, assuming you're not doing anything else. In reality, any app I've ever encountered probably has a few hundred querySelector calls, in total, and if the app is well written, the majority of these are cached meaning they only get called once, not once per frame.

[1] https://www.measurethat.net/Benchmarks/Show/2488/0/getelemen...

500k ops is ridiculously slow for accessing the DOM on any modern hardware. It sounds fast when aren’t comparing it to anything. Compare that to a similar approach that makes use of the standard DOM methods and no selectors. The only thing querySelectors do faster is allow accessing elements by attribute.

The reason I refuse to post numbers myself is because:

1. I provided a tool where people can run any manner of discovery for their own numbers and see performance differences in various approaches.

2. People, when presented with a valid comparison will irrationally ignore results that challenge their opinion.

EDIT:

I looked closer at the measureit experiments and it seems there is some sort of bias. If you run the same experiment using an element already present in the page the results are the same for querySelector but 50% greater for the getElementById approach. Other perf tools I have tried did not display this kind of bias and they also reported substantially higher numbers for all user agents, most especially for desktop Firefox.

In response to 1, you're asking people to do their own research when you have stated the claim. The burden is on you.

As for 2, if it's such a problem, just don't make the argument. It genuinely comes off as wanting people to agree with you rather than any real interest towards engaging in actual discussion.

> The burden is on you.

Then just disagree with me.

> 500k ops is ridiculously slow for accessing the DOM on any modern hardware. It sounds fast when aren’t comparing it to anything.

I didn't say it was fast OR slow. I just said it's not slow enough to be the problem that you're claiming it is.

If you disagree with this, could you provide evidence of a situation where accessing elements with strings is a bottleneck? As I said, I've never seen this in practice and if it can be the case I would like to know more.

> Compare that to a similar approach that makes use of the standard DOM methods

querySelector is a standard DOM method.

> and no selectors

I don't know what you're referring to here. Could you provide an example?

Here are some examples:

https://news.ycombinator.com/item?id=24057163

I've seen so many benchmarks for these selectors I basically know them by heart. I'm asking for a real world example where selectors cause slowdown.

It doesn't matter if they're slower than the alternative, it matters how they affect the overall performance of the app.

It's funny, you say

> It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers.

But your only argument here is not numbers, but appeal to authority:

> > I'm not a front end dev

> But I am.

I don't have any particular reason to doubt you, but if objective numbers should rule the day here, maybe you could link to an article comparing the performance of a simple application using CSS selectors and then switching to using the DOM API?

Could you provide said numbers? Maybe you have seen a lot of pathological cases, but that might not be representative.

I'm not the poster in question, but I thought it was pretty well known that querySelector[All] with a class string is shockingly slow - I'm actually a bit confused that everyone here is acting like they said something out of the ordinary. If that's really not common knowledge, it's probably no surprise that people are unintentionally writing websites that run like absolute crap on mobile devices.

Here's a JSPerf (not mine) that you can run and see yourself just how bad the performance is: https://jsperf.com/getelementbyid-vs-queryselector/284. getElementsByClassName runs nearly five million operations per second on my laptop (8th-gen i7, 16GB of RAM, latest Chrome); querySelector[All] with a class name runs less than ten thousand. And the sample HTML is tiny indeed compared to a typical web site or app.

I think what you're referring to is that querySelector is O(n), while the older getElement APIs are O(1).

https://stackoverflow.com/questions/14377590/queryselector-a...

That makes sense, but it has nothing to do with "string parsing", as the OP said. Parsing the query is fast. Executing the query is slow, because it's a more general API.

(And this is why the citation is important: because it shows the real issue, not the one described! Thanks for the clarification.)

See this: https://news.ycombinator.com/item?id=24058409

But still, please follow up on [citation needed] please

Then provide some numbers?

Do these work for you? https://jsperf.com/getelementbyid-vs-queryselector/284

I love how big the numbers are in recent versions of Firefox. On my crappy work computer that can barely run Notepad++ I am pulling 1.8 billion ops for getElementById and getElementsByClassName. The performance gaps:

* getElementById vs equivalent querySelector is about 1000x.

* getElementsByClassName vs querySelectorAll is about 250,000x.

* On Chrome getElementsByClassName vs querySelectorAll is only about 426x.

This is a micro-benchmark. In the real world that disparity would magnify almost exponentially with the number of nodes in a given page and the frequency and depth of access requests to the DOM.

I decided to check back in this and this seems like it was entirely a wording problem in your first post. Your post implied that _parsing the query selector string_ was slowing down Javascript websites, which obviously made everyone do a hottake and jump in to say that can't be the case. What you seem to _actually_ be saying is that using query selectors instead of finding elements directly by class/id is slow which yes, that's certainly the case.

Query selectors are slow, yes, but its because they have to parse a string. Other DOM methods don't have a string parsing step. You cannot optimize access to the DOM if there is a string parsing step that must occur first.

That barrier to efficiency is greatly magnified by the complexity of the query string, the size of the dynamically rendered page, and the number of query strings. If not for that string parsing step why would query selectors be any different from any other DOM access instruction computationally?

You're quite frankly leaping to conclusions quite a bit, as well as starting from the (rather flawed) premise that parsing a, what, ten-character string is so slow that it can slow an operation down by three orders of magnitude.

There are any number of reasons why the querySelector API would be computationally different from the getElementX ones, especially considering that they don't even return the same thing.

They return exactly the same thing: either null or a node or node list depending upon the method in question.

Any number of reasons like what? Could you provide an example of what would make those methods that much slower?

> They return exactly the same thing: either null or a node or node list depending upon the method in question

...this is another thing that I'm surprised to find that people don't know. Do devs really just use these methods without ever looking at what they return or how they behave?

getElementsByClassName returns a (live) HTMLCollection, not a NodeList. querySelectorAll returns a (static) NodeList. That in itself is an obvious computational difference/potential bottleneck, because the simplest way to implement a live collection is to cache and return the same object on subsequent calls for it. And that's precisely what browsers do (getElementsByClassName('foo') === getElementsByClassName('foo')). In other words, getElementsByClassName called multiple times with the same class doesn't actually do any extra work. The real work for the browser engine, which doesn't actually happen at the point of function call, is watching any tracked class names and updating their associated HTMLCollections when an element matching that class name is added or removed from the DOM.

On the other hand, gathering the static NodeList for a querySelectorAll call requires actually iterating over the DOM to find element(s) matching the selector every time (in the naive implementation), with the trade-off of the engine not having to watch the collection internally.

As an aside, the querySelector method with an ID selector is slower but on the same order of magnitude (a difference of about a few hundred thousand ops/sec for me) as the getElementById method. So if one looks at all the data in the benchmark and not just the class ones in isolation, it becomes clear that merely parsing the selector string is not enough to drop millions/billions of operations per second down to single-digit thousands.