Streaming compilation and the VM inside the browser

Every earlier lesson in this module built the WASM execution model from the inside: a stack machine that computes, linear memory that stores, a toolchain that produces the bytecode, a boundary that shuffles bytes across to JavaScript. This lesson turns around and looks at the other side of that boundary — the browser itself, at the moment a .wasm file arrives over the network. What does the engine actually do with those bytes between "the response started arriving" and "your exported function is callable"? The answer is a short, well-defined pipeline, and it's fast largely because of a design choice you already understand: the stack machine's instructions can be checked and translated in a single linear pass.

The naive way first: instantiate after the whole file arrives

The simplest way to load a WASM module from JavaScript looks like this:

const response = await fetch("module.wasm");
const bytes = await response.arrayBuffer();
const { instance } = await WebAssembly.instantiate(bytes, imports);

Read that sequence of awaits literally and you can see the cost hiding in it. fetch has to finish — every byte of module.wasm has to arrive over the network — before response.arrayBuffer() can resolve. Only once the entire binary is sitting in memory as an ArrayBuffer does WebAssembly.instantiate get to start doing anything: parsing the binary format, validating it, compiling it to machine code. Two phases, strictly ordered, back to back: first download the whole thing, then compile the whole thing. For a large module — and WASM modules compiled from real C++ or Rust codebases can be megabytes — that's real, visible time added to your page's startup, none of it overlapping with the other.

The streaming way: compile as the bytes arrive

WebAssembly.instantiateStreaming collapses those two phases into one:

const { instance } = await WebAssembly.instantiateStreaming(
  fetch("module.wasm"),
  imports
);

Notice what's passed in: not a resolved ArrayBuffer, but the fetch() call itself — a Promise<Response> whose body hasn't necessarily finished streaming yet. instantiateStreaming takes that response and feeds it, chunk by chunk, straight into the engine's parser and compiler as the network delivers them, instead of waiting for a complete buffer. The engine can start validating and compiling the first function in the module while the last function is still in flight over the wire. Compilation overlaps download instead of following it, and for a module large enough that download time is significant, that overlap can hide most or all of the compile time behind time you were going to spend waiting on the network anyway.

This is why instantiateStreaming is the recommended way to load WASM in production and instantiate(await response.arrayBuffer()) is treated as the fallback: the streaming form isn't a different algorithm bolted on for convenience, it's the same validate-then-compile work, just no longer artificially serialized after the download instead of alongside it.

Why a stack machine is what makes this possible

Overlapping compilation with download only works if the engine can make forward progress on a partial file — and that's only safe if the format is designed so a prefix of the bytes is self-contained enough to validate and compile without knowing what comes later. This is the payoff of the stack-machine design from the first lesson in this module: because every instruction declares exactly how many values it pops and pushes, and the type of each, the engine can walk the instruction stream once, left to right, tracking the abstract stack of types as it goes, and know immediately whether each instruction is valid — never backtracking, never waiting to see a later part of the function to make sense of an earlier one. A register machine or a format with more entangled cross-references would make this same trick far harder, because validating instruction N might depend on information that only shows up in instruction N+50. WASM's binary format was built with streaming in mind from the start: functions are laid out so the engine can validate and compile one function completely before it needs to look at the next.

Validation: the gate before anything runs

Before the browser executes a single instruction from a .wasm file, it validates the whole module. Validation means confirming, statically, that the module is well-typed and internally consistent — that no instruction sequence ever pops a value of the wrong type off the operand stack, that every branch target actually exists, that every function call matches the signature it claims to call, that memory and table indices are within the declared bounds where that can be checked ahead of time. This is exactly the "trivial to validate" property the flagship lesson introduced: because the stack machine's type discipline can be simulated without executing anything — just walking the instruction stream and tracking what type of value would be on top of the stack at each point — validation is a single linear pass, not a search or a fixed-point analysis. That's what makes it fast enough to run on every module, every time, with no way to opt out. A .wasm file that fails validation is rejected outright; nothing from it ever runs, optimized or not. This one gate is the foundation the whole security story sits on — it's the reason the engine can trust every later assumption it makes about the module's behavior.

Two compilers, not one: baseline first, optimizing second

Once a function has validated, it still has to become actual machine code, and here engines make a deliberate trade-off between two different compilers rather than picking one.

The baseline compiler — V8 calls its Liftoff, and it plays the equivalent role in SpiderMonkey and other engines — does the simplest possible translation from validated WASM bytecode to machine code, function by function, as fast as it can. It doesn't try to produce great code; it tries to produce code, quickly, so the module can start running with minimal delay after the bytes are validated. This is the compiler doing the work in the streaming diagram above, running chunk by chunk as the file downloads.

The optimizing compiler — TurboFan in V8's case — runs later, in the background, on functions the engine has noticed are actually hot (called often, or burning significant time). It applies the expensive analyses and transformations — better register allocation, inlining, more aggressive instruction selection — that produce genuinely fast machine code but take meaningfully longer to generate. When the optimized version is ready, the engine swaps it in for future calls to that function, transparently.

If this sounds like the tiered JIT pipeline a JS engine already runs for hot JavaScript functions, that's not a coincidence — it's the same underlying idea, get something running fast, spend the expensive optimization budget only where it's earned. But WASM's version of this is meaningfully simpler than JavaScript's, for a reason that traces straight back to the type system: WASM functions have static, fixed types on every value and every parameter, decided at compile time and never changing. A JS JIT has to speculate about types it can't know in advance — assume a variable will always hold a number, generate fast code for that assumption, then deoptimize and fall back to a slower path if the assumption turns out wrong at runtime. WASM's optimizing compiler never needs a deopt path, because there's no dynamic-typing surprise to guard against; the types were already nailed down and validated before either compiler ever ran. Tiering up is strictly a "spend more time producing better code for the same known types," not a bet that might have to be unwound.

The sandbox: what a running module can and can't touch

Compilation gets a module into a runnable state, but "runnable" doesn't mean "unrestricted." Once instantiated, a WASM module's access to the outside world is entirely capability-based: it can read and write its own linear memory (bounds-checked on every access, as the linear memory lesson covered), and it can call whatever functions the host explicitly passed in through the imports object at instantiation time — nothing else. There is no instruction in the WASM instruction set for "open a file," "make a network request," or "read a DOM node." If a module calls console.log-equivalent functionality, or fetches a URL, or touches localStorage, it's because the embedding JavaScript handed it a specific imported function that does that on its behalf — the exact mechanism the JS/WASM boundary lesson walks through in detail. Take away the imports, and a WASM module is an inert island: it can compute against its own memory and nothing more.

This is a meaningfully different security model from "run this code but sandbox dangerous operations," which is how a lot of software sandboxing works — start permissive, then subtract. WASM starts at zero: a module has no ambient authority to do anything beyond arithmetic on its own bytes, and every capability beyond that has to be explicitly granted, one import at a time, by whoever instantiates it. That's what makes it plausible to download and run a .wasm file from a source you don't fully trust — the worst it can do is whatever the finite list of functions you handed it allows, and nothing the validator didn't already rule out.

Why this all adds up to fast, safe startup

Put the pieces together and the reason WASM modules start up quickly and safely stops being a marketing claim and becomes a mechanical consequence of specific choices: a stack-machine bytecode designed to validate in one linear pass, a binary layout that lets that pass run function by function as bytes arrive, a streaming API that overlaps that pass with the download itself, a fast baseline compiler that gets code running the moment validation clears, an optimizing compiler recompiling only the functions worth the expense, and a capability-based sandbox that means none of this speed comes at the cost of letting untrusted code touch anything it wasn't explicitly given. Every one of those pieces reaches back to a lesson earlier in this module. None of them is an accident.

Where this goes next

Everything so far has been the browser's story — a .wasm file arriving from a server, compiled and run inside a JS engine. But nothing about the stack machine, linear memory, or the capability-based sandbox is actually browser-specific; they're properties of the format and the execution model, not of where that engine happens to be embedded. Beyond the browser picks up exactly that thread — what it takes to run the same .wasm file on a server, at the edge, or as a plugin host, with no browser and no JavaScript engine in sight.