Linear Memory, the JS Boundary & When to Use WASM

Linear Memory: A Flat Byte Array

WASM modules operate on linear memory — a single, contiguous, resizable block of bytes, manually managed like C/C++ memory. WASM function signatures only support numeric types (integers, floats), so richer data must be written into this buffer at known offsets rather than passed directly.

Crossing the Boundary

const buffer = new Uint8Array(instance.exports.memory.buffer)
const ptr = instance.exports.alloc(str.length)
buffer.set(new TextEncoder().encode(str), ptr)
instance.exports.process(ptr, str.length)

Passing a string means manually encoding it into linear memory and passing a pointer + length — tedious to do by hand, which is why tools like wasm-bindgen (Rust) generate this glue code automatically. Frequent small crossings still carry marshaling overhead, so WASM pays off most for larger, self-contained chunks of computation rather than many tiny chatty calls.

Why Rust Fits WASM Particularly Well

Rust manages memory at compile time via ownership/borrowing rather than a garbage collector, mapping naturally onto WASM's manual linear-memory model without needing to bundle a GC runtime — one reason Rust became a especially popular WASM source language.

Good Fits vs. Bad Fits

WASM shines for sustained CPU-bound work: image/video processing, physics simulation, cryptography, or porting an existing native codebase (a game engine, a video codec) into the browser without a full rewrite. Simple DOM manipulation or a one-off fetch call gets no benefit — that stays squarely in JavaScript's comfort zone.

Beyond the Browser

WASM's portability and sandboxing made it attractive outside browsers too — standalone runtimes like Wasmtime and WasmEdge run it on servers and at the edge, with WASI (WebAssembly System Interface) standardizing capability-based access to files, clocks, and other system resources when there's no browser host providing them.