Hacker News Reader

Comment by esperent | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com