3 ms·

JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C ve

JavaScript is still really slow compared to compiled languages - C, C++, even Java. That super-simple benchmark even after JIT is still 2-3x as slow as the C version, and more complex code can’t be optimized nearly as well. I can confidently say that games and apps in the browser and Electron are noticeably slower than other apps. 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, at least until WebGL2/WASM/WebGPU get better support. But JavaScript is fast enough. Because the vast majority of programs, especially websites, don’t need really fast code like C. They don’t need to redraw every frame, don’t need 3D capabilities, don’t need to perform expensive computations, etc.. If you need a fast program that does those things 99.9% of the time you can just make it a real app, or you can write the fast parts in WebAssembly. At the end of the day computers are very fast, so a program could be written in any language as long as it isn’t doing anything super performance-needing and the compiler/interpreter has has half-decent optimization.

brundolf 5y ago
> 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
- josephg 5y ago
  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.
  - brundolf 5y ago
    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.
- chrismorgan 5y ago
  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.
tasogare 5y ago
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.
- codyswann 5y ago
  Is that a problem?
- rndgermandude 5y ago
  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/3062e92bf2f9f018f497239396dccb9685428cc0/2014/10/04/f000f288-4b73-11e4-b6a0-d4ae52e95e57/browsersssjb061608sm.png?fit=bounds&auto=webp https://www.zdnet.com/a/img/resize/3062e92bf2f9f018f49723939... Full size image url is broken :P
  - tasogare 5y ago
    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.
jjnoakes 5y ago
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).
pyentropy 5y ago
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.
- genewitch 5y ago
  All that stuff in your last point is for telemetry, isn't it? That is, fingerprinting.
  - pyentropy 5y ago
    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-info.html?allDevices=true https://googlechrome.github.io/samples/web-bluetooth/device-...
thaumasiotes 5y ago
> 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.
johnisgood 5y ago
> 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?!

brundolf 5y ago

> 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

josephg 5y ago
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.
- brundolf 5y ago
  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.
chrismorgan 5y ago
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.

tasogare 5y ago

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.

codyswann 5y ago
Is that a problem?
rndgermandude 5y ago
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/3062e92bf2f9f018f497239396dccb9685428cc0/2014/10/04/f000f288-4b73-11e4-b6a0-d4ae52e95e57/browsersssjb061608sm.png?fit=bounds&auto=webp https://www.zdnet.com/a/img/resize/3062e92bf2f9f018f49723939... Full size image url is broken :P
- tasogare 5y ago
  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.

jjnoakes 5y ago

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

pyentropy 5y ago

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.

genewitch 5y ago
All that stuff in your last point is for telemetry, isn't it? That is, fingerprinting.
- pyentropy 5y ago
  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-info.html?allDevices=true https://googlechrome.github.io/samples/web-bluetooth/device-...

thaumasiotes 5y ago

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

johnisgood 5y ago

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