Hacker News Reader

Comment by RobbieGM | Hacker News Reader

He makes a point of showing how hard it is to achieve the same performance as JS with wasm, but the majority of the problems he runs into are AssemblyScript-related. Also he doesn't mention that wasm is faster to parse than JS. I'd be interested in a comparison of JS and wasm from the POV of a UI-heavy, compute-light app.

View on HN

js-framework-benchmark is the standard benchmark for UI-heavy, compute-light JS. https://krausest.github.io/js-framework-benchmark/current.ht...

To see results, show "vanillajs-1" and "wasm-bindgen", then hide everything else. WASM is about 6% slower, 18% longer startup, and 66% more memory usage.

Note this is a UI benchmark so the results are overwhelmingly dominated by DOM interop. Things should improve if the WASM interface types proposal ever lands.

I get that it would have a startup cost but I'm shocked that it uses more memory. Everyone complains about what a memory hog electron apps are and I assumed it was because of JS. But maybe we need something other than micro benchmarks to compare.

The absolute numbers aren't that different. You need 100s of MB just to display an empty Chrome window. Then the 66% is the difference excluding that baseline, e.g. it might be 300MB to load Chrome, then you measure 301MB vs 301.66MB. I guess that might be a bit misleading.

I think the electron memory usage comes down to the massive HTML spec and bloated old browser codebases. It's not JS. Node+V8 doesn't have nearly the memory usage of Chrome+V8.

That difference is what I'd be interested in anyway as a developer who focuses on PWAs (where the cost of chrome is paid for already). I'm trying to work out whether a WASM stack would help runtime performance, memory usage, and startup time, but based on these numbers it doesn't look so inspiring.

While just the parsing step may be faster indeed, I don't think that aspect alone is enough to make a difference for an application.

Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time.

In JS first run goes through an interpreter (without a delay for compilation/optimization), so JS has a pretty low latency for initial execution.

JS is relatively easy to split into pieces and lazy load (there are various bundlers that support "chunking"), and not loading code is faster than fastest parsers. WASM could theoretically do that too, but current languages and tooling are more geared towards monolithic executables. For UI, where time to interactive matters most, JS will likely do a better than a big blob of WASM.

WASM still needs to call out to JS for DOM interactions, so if your UI is DOM-based, you'll need a bunch of JS anyway, and have JS<>WASM communication overhead.

Does wasm support anything other than monolithic executables? The last I used it, multiple wasm bundles had to be loaded up by JavaScript and glued together with JavaScript.

> Browsers are often able to defer parsing of JS functions until they're called, so dead JS code doesn't cost much in parsing time.

You sure? Just figuring out what to call us going to typically require full parsing to find identifiers, scoping, etc.

Browsers do a fast partial parse to figure out things like scoping and variable names, but skip actually building an AST so it's still a lot quicker than full parsing (e.g. https://v8.dev/blog/preparser)

Reply on news.ycombinator.com