Hacker News Reader

This line of reasoning works adequately when looking at a single program, but when you look at a larger group of programs, performance still matters. The more performant each individual program, the more programs can be run simultaneously.

This helps everywhere: mobile (better battery life, smarter apps), desktop (more apps open without swapping), server (more compute in the same footprint), and embedded (smarter devices, less power, cheaper hardware).

> I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps

In my experience the great majority of perceptible slowness in browser apps comes from DOM reflows, not JavaScript

I’ve also seen plenty of web apps which load slowly because they load too much javascript. Most of it unused. I was asked to help out with one project my coworkers were working on where the bundler was pulling in multiple copies of momentjs, each complete with its own copy of the global time zone database. The page loaded way faster once we cleared that out.

A few years ago I noticed most websites just seemed slower than they should on my computer. The culprit turned out to be metamask (an etherium wallet extension). It was adding 700 kilobytes of javascript to each page load thanks to web3. It also exposed my etherium address to any website that asked.

The JS was cached, but just parsing that much code added noticeable lag to every page load. Everything felt zippy once I uninstalled that.

Loading assets != running JavaScript, which is what we're talking about here. It's also a difference between startup slowness and long-running slowness. And Electron, for example, would (normally) only ever be "loading" JavaScript from disk, like any other local app would.

In my experience, the great majority of perceptible slowness comes from badly-written JavaScript and running too much code, generally not even code that touches the DOM, though certainly touching the DOM too much in bad ways (and structuring the DOM in bad ways) often contributes to it.

Certainly the web as a platform is slower than a precisely-built thing honed for speed for a particular use case, but speaking generally the web is only perceptibly slow when you write bad code (or are waiting for the network). Which is admittedly rather common.

Electron apps are memory heavy and slow at interaction because Chromium loads a ton of rendering and Web API code into memory, and interactions triggered by keyboard/mouse/touch input go through layers of non native handlers so that event listeners behave uniformly across devices. It's all part of a complex rendering loop, and whether an element has a fixed position during scroll can affect memory and performance by hundreds of times compared to those 2x js-vs-native you mention.

Oh, and the Web API has has stuff you wouldn't expect like USB, Bluetooth, MIDI, vibration, TPM etc.

All that stuff in your last point is for telemetry, isn't it? That is, fingerprinting.

No, most of them require some interaction like a click or there's a dialog requesting access.

Here's a Web Bluetooth example: https://googlechrome.github.io/samples/web-bluetooth/device-...

> You don’t see many web games because the graphics required for games today can’t really be rendered on the web in 20+ FPS

Nonsense. There's nothing wrong with the graphics you can run on the web. Web games flourished before the iPhone. And it seems safe to assume that they died because of the iPhone.

It was a horrific development in the space, since mobile games differ from flash games in being (1) more expensive and (2) worse.

It's fast now because a bunch of mega-corps (Google, Apple, Microsoft before dropping the ball) put a huge investment in making JavaScript interpreters fast.

Is that a problem?

mozilla gets no credit at all? According to some old zdnet benchmarks I could google up[1], their IE7's sunspider was result was 22678ms, Firefox 2's result was 12460ms, Firefox 3 RC1 2377ms. So mozilla managed to make their Firefox 3 js engine about 10 times faster than IE7 in sunspider, more than 5 times faster than Firefox 2. Safari at the time was pretty much on par with Firefox 3. That's before any public Google Chrome release (their first release was a few months after Firefox 3 stable). After the Chrome release, js perf mostly became an arms race between Google and mozilla with the other vendors trying to not be left too far behind in the dust.

Of course, in current gen browsers and on current gen hardware, sunspider is so fast it's more noise than measurement.

[1] https://www.zdnet.com/a/img/resize/3062e92bf2f9f018f49723939... Full size image url is broken :P

Mozilla is funded at 90+% by Google, whatever they spend it's mostly Google's money originally so it doesn't make sense to count them as a separate entity investing on that front.

> At the end of the day computers are very fast

Well, my problem with the testing process that goes into many programs is that they only test with decent hardware. What about those who do not have the latest, state of the art computer or smartphone?!