4 ms·

More specifically the culprit is generally unnecessary string parsing. Every CSS selector, such as querySelectors and jQuery operations, requires parsing a stri

More specifically the culprit is generally unnecessary string parsing. Every CSS selector, such as querySelectors and jQuery operations, requires parsing a string. Doing away with that nonsense and learning the DOM API could make a JavaScript application anywhere from 1200x-10000x faster (not an exaggeration). Most JavaScript developers will give up a lung before giving up accessing the page via selector strings. Suggestions to the effect are generally taken as personal injuries and immediately met with dire hostility.

chubot 6y ago
[citation needed] There are a lot of other reasons why client side JS is slow, including page reflows, bad use of the network, etc. I'm not a front end dev but I have fixed many performance problems before, and I've never seen parsing CSS selectors as a bottleneck. I've seen some data driven work like this: https://v8.dev/blog/cost-of-javascript-2019 https://v8.dev/blog/cost-of-javascript-2019 I don't think they mentioned parsing CSS selectors anywhere. Shipping too much code is a problem, because megabytes of JS is expensive to parse, but IIUC that is distinct from your claim.
- austincheney 6y ago
  > I'm not a front end dev But I am. You are correct in that there many other opportunities to further increase performance. If performance were that important you would also shift your attention to equally improve code execution elsewhere in your application stack. > and I've never seen parsing CSS selectors as a bottleneck. 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. EDIT To everybody asking for numbers I recommend conducting comparative benchmarks using a perf tool. Here is a good one: http://jsbench.github.io/ http://jsbench.github.io/ I posted a performance example to HN before and people twisted themselves into knots to ignore numbers they could easily validate and reproduce themselves.
  - bscphil 6y ago
    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?
  - pas 6y ago
    Could you provide said numbers? Maybe you have seen a lot of pathological cases, but that might not be representative.
    - filleduchaos 6y ago
      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 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.
      - chubot 6y ago
        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-and-queryselectorall-vs-getelementsbyclassname-and-getelementbyid/54819633#54819633 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.)
fermienrico 6y ago
At this point, we need to reimagine what a web browser is and how it should be. It cannot happen since we want backwards compatibility.

chubot 6y ago

[citation needed] There are a lot of other reasons why client side JS is slow, including page reflows, bad use of the network, etc. I'm not a front end dev but I have fixed many performance problems before, and I've never seen parsing CSS selectors as a bottleneck. I've seen some data driven work like this: https://v8.dev/blog/cost-of-javascript-2019 https://v8.dev/blog/cost-of-javascript-2019 I don't think they mentioned parsing CSS selectors anywhere. Shipping too much code is a problem, because megabytes of JS is expensive to parse, but IIUC that is distinct from your claim.

austincheney 6y ago
> I'm not a front end dev But I am. You are correct in that there many other opportunities to further increase performance. If performance were that important you would also shift your attention to equally improve code execution elsewhere in your application stack. > and I've never seen parsing CSS selectors as a bottleneck. 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. EDIT To everybody asking for numbers I recommend conducting comparative benchmarks using a perf tool. Here is a good one: http://jsbench.github.io/ http://jsbench.github.io/ I posted a performance example to HN before and people twisted themselves into knots to ignore numbers they could easily validate and reproduce themselves.
- bscphil 6y ago
  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?
- pas 6y ago
  Could you provide said numbers? Maybe you have seen a lot of pathological cases, but that might not be representative.
  - filleduchaos 6y ago
    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 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.
    - chubot 6y ago
      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-and-queryselectorall-vs-getelementsbyclassname-and-getelementbyid/54819633#54819633 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.)

fermienrico 6y ago

At this point, we need to reimagine what a web browser is and how it should be. It cannot happen since we want backwards compatibility.