Core Idea
Step through the two machines above and watch the same hot function live two different lives. WebAssembly is the browser’s second language for the CPU: a compact binary format that languages like Rust and C++ compile to, and that the browser executes at near-native speed. It is not something you write by hand, and it is not a JavaScript replacement — JS keeps the DOM, the events, the scene graph (Three.js stays JS). WASM takes over exactly one kind of work: heavy, predictable number-crunching that JavaScript’s flexibility makes expensive.
The Tax It Skips
The left lane of the machine is the tax itemized. JavaScript is dynamically typed, so the engine spends real cycles negotiating: parse the text, interpret while a profiler watches, JIT-compile on guessed types — and when a float lands in a loop the JIT assumed was integers, the optimized code is thrown away and the warm-up starts over (the deopt beat). Usually the guesses land — but the warm-up costs time and a wrong guess costs a recompile, at a moment the engine chooses, not you. WASM arrives already compiled, with every type fixed in the file, so there is nothing to guess, nothing to warm up, and nothing to revoke: its lane stops changing state at beat three and never moves again. The headline isn’t just speed — it’s predictability: the same function takes the same time every frame, which is exactly what a 16 ms budget wants.
One Flat Memory
A WASM module owns a single linear memory — one contiguous, growable block, like a typed array the size of the whole program, managed manually. The garbage collector never scans it, never compacts it, never pauses it: a physics world’s worth of state can churn every frame without a single collection hitch. JavaScript reads and writes the same block directly through typed-array views — which is also the fast path across the border.
Not a GPU Technology
WASM cannot touch the GPU. It is a faster CPU, full stop — so it competes with JavaScript, never with shaders. On the CPU-vs-GPU map: if your frame is fragment-bound, WASM buys you nothing; if it’s stuck in JavaScript-side simulation or preparation, WASM is the lever. In modern in-browser ML the split is explicit — WebGPU compute shaders do the matrix math while WASM tokenizes and marshals data on the CPU side. Partners, not rivals.
Where It Earns Its Keep in 3D
- Physics — collision, cloth, rigid bodies at frame rate (Rapier, Ammo — C++/Rust engines compiled to WASM).
- Mesh decompression — Draco-compressed GLTF geometry is inflated to vertex data by a WASM decoder before it ever becomes a mesh; Three.js ships this path.
- Procedural generation — noise fields, voxel meshing, geometry processing too hot for JS loops.
- ML pre/post-processing — tokenizers and tensor plumbing around GPU inference.
In practice you rarely compile anything: libraries ship the .wasm internally and you call them from ordinary JavaScript.
The Boundary Tax
The one cost that surprises: crossing the JS↔WASM border is not free. A chatty design — thousands of tiny calls per frame, each copying arguments across — can burn the entire speedup. The pattern that works is coarse: hand WASM a big job (or leave the data living inside its linear memory and read it through views), take a big result back, cross the border a handful of times per frame.
Connections
WASM is the CPU-side answer to the same question WebGPU answers for the GPU: how does the browser stop being the slow option? Its linear memory is the buffers idea promoted to a whole program — typed, flat, and invisible to the garbage collector. Whether it helps at all is a CPU-bound-or-GPU-bound diagnosis, and its most common cameo in a 3D pipeline is quietly decompressing the meshes a scene loads.