As surprising as it might sound -- not really. There's a small-but-non-trivial amount of overhead involved in calls between WASM code and the DOM API's, plus (de)serialization.
It's more of a familiarity/existing tooling thing. Same as Blazor in C# writing web apps in that. If your entire team only knows C# and you have all your existing tooling there then it could seem an appealing option.
But there's also the argument for more stringent safety with Rust compared to IE, Typescript.
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.
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.
Now I'm somewhat tempted to write a js implementation to actually compare.
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.
> 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.