WebAssembly is still mostly a “use it when you actually need it” thing, and this piece walks through the usual Rust/Emscripten setup, where the speed wins show up, and where Wasm still gets kind of annoying in real web apps.
Wasm speed is real, but the part that keeps biting me is the JS↔Wasm boundary. You get the wins when you can hand over one big, boring chunk of work, keep the data in linear memory, and not ping-pong across the boundary 1,000 times; once you’re copying buffers or trying to “pass objects,” the overhead shows up immediately.
Kirupa has a good write-up on interop/data passing that made this finally click for me.
That JS↔Wasm boundary tax is so real. I’ve had the best results treating Wasm like a dumb little appliance: typed arrays in/out, and anything “webby” (DOM, fetch, strings) stays in JS where it belongs.
The shared WebAssembly.Memory + views trick is clutch too, because a lot of the “why is this slow??” moments end up being accidental copies from stuff like slice() or spreading arrays. Mutating a Uint8Array view in place and letting Wasm chew on it is basically the only way I’ve gotten consistent wins without turning the code into a science project.
Curious what toolchain you’re on though—Rust + wasm-bindgen vs Emscripten feels like two totally different worlds once you touch strings/structs, and I’m not even sure there’s a single “best” approach there.
The “shared memory + views” bit you mentioned is the part that gets me, because it quietly falls apart the first time the Wasm side grows memory and your JS TypedArray views go stale and keep pointing at the old buffer. I don’t know if you’ve hit that yet, but do you have a pattern for “reacquire the views after a possible memory. grow” so you don’t end up debugging phantom corruption at 2am? not sure on that side.
