5 ms·
> Speed? 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'
by gavinray 6y ago
> Speed?
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.
- danShumway 6y ago> 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.
- gavinray 6y agoThat'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/proposals/interface-types/Explainer.md 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/ https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
- markdog12 6y agoFirefox Nightly and Chrome Canary both recently landed multi-value and reference types: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
- dom96 6y agoI 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.
- gavinray 6y agoSame, 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 https://v8.dev/features/simd
- FridgeSeal 6y agoV8 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.
- dom96 6y agoI 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.
- paulgb 6y agoThis 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/ https://crossword.paulbutler.org/