Track W

WebAssembly, under the hood

What that .wasm file really is: a stack-machine bytecode, its flat linear memory, the compile toolchain, the JS boundary, why it is fast, streaming compilation, and WASI beyond the browser.

1. What WebAssembly actually is: a stack machine and bytecode

   A .wasm file is not a language, not a faster JavaScript, and not a container — it is a compact binary encoding of instructions for an imaginary CPU that computes by pushing and popping a stack. This lesson builds that stack machine in your head from a three-instruction example, so every later idea (linear memory, the JS boundary, why it's fast) has something concrete to attach to.

   12 min
2. Linear memory: the flat array everything lives in

   The stack machine from the last lesson can compute a sum, but it has nowhere to keep a string, a struct, or an array — linear memory is that place, a single contiguous block of bytes addressed by plain integers, and this lesson builds it from first principles the same way the last one built the stack.

   13 min
3. Compiling to WASM: the toolchain from Rust and C

   WebAssembly is a compile target rather than a language anyone writes by hand, and this lesson traces the actual pipeline that turns Rust or C source into a .wasm stack-machine module, why that pipeline is so much smoother for languages with a flat manual memory model, and where the friction still is for the ones without one.

   13 min
4. The JS and WASM boundary: calls, numbers, and shared memory

   WebAssembly never runs alone in the browser — JavaScript instantiates it, calls into its exports, and hands it imports to call back out — but the calling convention only lets raw numbers cross that boundary directly, so every string, object, or array has to be encoded into the shared linear memory first and referenced by a pointer and a length.

   13 min
5. Why WASM is fast — and when it isn't

   WebAssembly's speed comes from a short list of nameable properties — ahead-of-time compilation with no warmup, static types with no runtime checks, and a flat cache-friendly linear memory — and every one of those properties stops helping the moment a workload is dominated by DOM calls, chatty boundary crossings, or garbage-collected data, which is why reaching for WASM is a judgment call, not a reflex.

   13 min
6. Streaming compilation and the VM inside the browser

   A .wasm file doesn't wait to finish downloading before it starts turning into machine code — the browser validates and compiles it in the same linear pass it uses to receive the bytes, and this lesson traces that pipeline from network response to running code, and from a quick baseline compile to a fully optimized one.

   13 min
7. Beyond the browser: WASI and the component model

   Nothing about the stack machine, linear memory, or the capability-based sandbox actually requires a browser, and this lesson traces the two pieces of infrastructure — WASI's portable syscalls and the component model's typed interfaces — that turn that same execution model into a universal, sandboxed compute target running on servers, at the edge, and as plugins.

   13 min
8. Threads, SIMD, and where WASM is going

   Core WebAssembly is a single-threaded, scalar stack machine, but a set of post-MVP proposals — SIMD for data parallelism, threads for true multicore execution, and a managed-heap GC on the way — are steadily turning it into as complete a compute target as native code, and this closing lesson traces each one back to a mechanism earlier lessons already built.

   14 min