However if I am loading Reddit, I expect it to be fast, and it seems the websites that should load the fastest are now loading the most 'non-essential' JS, leading to worse performance than peoples expectations.

In my experience JS adds at most hundreds of miliseconds, and thats because people add dozens of marketing/tracking code that bog the site down.

If you run ghostery / ublock the javascript eval time shrinks dramatically. Our web app has a very large Angular app and it still renders in under 200ms, but we don't have any "plugins" due to working with PHI.

And how do you think that happened? It's not a chicken-and-egg problem. Web pages got fat, and users' expectations got lower. Lazy devs have trained people to expect the worst, not the best. The app ecosystem wouldn't be half the size it is if web pages worked as fast as native apps.

If you run ghostery / ublock the javascript eval time shrinks dramatically.

Are you going to be the one to explain to the marketing department why you put instructions for doing so at the top of each of your company's web pages?

Edit: Also, I find it comical that when you include recaptcha v3 on your website, your page speed insight score can drop almost 20 points. It is as if google don't want you to use recaptcha at all.

Which is ridiculous and just builds in the ability to game the system, because in my experience, amp pages take upwards of 5-8 seconds before anything of use to me actually loads, while the non-amp version loads in a fraction of that time.

I imagine someone is benefiting from amp, otherwise it wouldn't be used, but I have not experienced a single case where the amp version of a site wasn't significantly slower.

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.

I've seen some data driven work like this: 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.

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/

I posted a performance example to HN before and people twisted themselves into knots to ignore numbers they could easily validate and reproduce themselves.

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

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.

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.

Then just disagree with me.

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?

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

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

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.

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

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

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?

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.

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

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

It cannot happen since we want backwards compatibility.

Slowest site I've tested so far had a page size of 8.5MB, 80% of that was images.

edit: Just looked it up. header has a logo and 5 links. footer has a scroll to top button and 10 links. both responsive. How many lines of code you ask? A little over 3400.

JS in of itself is not a performance issue in many cases. It can even improve performance in terms of speed/responsiveness.

In other words, there are too many websites that are made as "web apps" that should not be web apps.

I wholeheartedly believe that when we solve the issue of undervaluing personal information... that's when Ads become nearly worthless (like they are in print media) and software salaries deflate to the point where those useful by humans tools become the primary product again - instead of tools to use harvesting from humans.

But, I'm quite an optimist - and a cynical one at that.

A more reasonable reason might just be that trying to be a platform of everything is a complex proposition and they've accepted so much complexity that all their labour at this point is being poured into maintaining that complexity rather than making improvements.

Without javascript the second tab would be a link to another HTML page where the second tab is shown. Exact same behaviour for the user, however the one with a few lines of javascript will feel way more responsive than the one without, where the user has to wait for a new page to load.

[1] https://getbootstrap.com/docs/4.0/components/navs/#javascrip...

https://codepen.io/dhs/pen/diasg

In this case the search is instant. Without JS you would have to have a submit button and wait for the request. Even if you also added a button the JS version it would still feel more responsive, as again, you're not waiting for the request.

[1] https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js...

Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.

I have also seen the horrible half/half implementations you mention where it should have just been implemented on the server side, and I totally agree with you there.

However it was just an example to show that a unsubstantiated blanket statement like “responsiveness never” is just wrong. I’m not saying doing search in JS is always (or even often) better, but it can be sometimes if done well.

Or you can do it in CSS actually instantly.

And no, complexity generally doesn't negate this. Earlier this year I built a series of complicated medical forms for a healthcare web site that are all HTML + CSS + < 2K of jsvascript, and they all respond instantly because I did't lean on JS to do everything.

The pages are fast, responsive, work on any device, almost any bandwidth (think oncologists in the basement of a hospital with an iPad on a bad cellular connection), and the clients are thrilled.

If you use Privacy Badger or similar plugins, you see that it's not uncommon for websites to have an obscene amount of these.

TLDR: I think ads are slowing the internet down way more than React apps.

Developers are careless because JS is so fast, but they forget the hundreds of milliseconds of GC-pauses that occur because they never think about the memory they are allocating and throwing away each second.