> There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization

My understanding is that this is going to get a lot better in the future though -- last I checked the plan was for WASM to eventually have direct bindings to DOM APIs, at which point you won't need to interact with JS at all.

That's true, if the Interface Types proposal gets accepted that overhead should be significantly less. At that point it'll get really interesting what the potential performance looks like for DOM-interaction heavy apps.

https://github.com/WebAssembly/interface-types/blob/master/p...

I wouldn't think it's far behind. The Multi-Value proposal, which had huge ramifications, was recently accepted in April so WASM is clipping along at a fair pace still.

https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/

Firefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/

This is true if you are writing code that has a lot of UI interaction, but one sweet spot for WASM I've found is if you just want to do a bunch of computation on the client and surface it. For example, I wrote a SPA for generating crossword puzzles[1]. Maybe I'm wrong, but I don't think I would have been able to get the same performance in JS even with modern optimization.

1. https://crossword.paulbutler.org/

That's really cool, thanks for sharing it. It found a 16x16 with a lot of complexity incredibly fast!

Nice crossword generator!

Now I'm somewhat tempted to write a js implementation to actually compare.

I was very surprised to find this. I have done some WASM experiments and found that JS is very often incredibly well optimised, often running faster than WASM. Do not underestimate the years of JIT optimisations that went into V8 and other JS engines.

V8 is an incredible piece of machinery, and I really wish other JIT's and languages got access to half the engineering and monetary effort that went into it.

> often running faster than WASM

This seems pretty counter to everything I've read about WASM - V8 is some black magic, but WASM should run far faster. What language was the WASM blob compiled from? Mozilla has also demonstrated that they can send the DOM to a WASM blob, have it perform the necessary transformations and return it, faster than JS could perform the same transformations itself.

I was actually playing with the raw WASM, but I checked what Rust compiled to and ran it as well (it wasn't any better). It was a simple fibonacci benchmark so perhaps not representative but it still left me very disappointed.

Same, do NOT underestimate V8 black magick + optimizations.

I've done a fair bit of benchmarking/performance experimentation with compiling Rust/Go/Zig etc to WASM (including with SIMD or parallelization enabled).

It'll be really interesting watching the progress of V8 + WASM SIMD proposal, it's been enabled behind a flag in V8 for some time now.

https://v8.dev/features/simd