🧩 WebAssembly Concepts

What Is WebAssembly?

WebAssembly (usually shortened to WASM) is a portable binary instruction format for a stack-based virtual machine. That's a mouthful, so let's unpack it one word at a time:

• Binary — it ships as compact bytes (.wasm files), not human-readable text, so it downloads fast and parses quickly.
• Instruction format — it is a low-level list of operations (add these two numbers, load this byte from memory) very close to what a CPU understands.
• Portable — the same .wasm runs identically in every modern browser and in server runtimes, regardless of the operating system or chip.
• Compile target — you don't usually write WASM by hand. You write C, C++, Rust, Go, or AssemblyScript and a compiler produces the .wasm for you.

What WebAssembly is not

WebAssembly is not a replacement for JavaScript, and it is not a programming language you'll write day to day. It has no built-in access to the DOM, no garbage collector of its own (in its core form), and no way to make a network request on its own. It is a fast, safe execution engine that JavaScript drives. The two are partners: JS orchestrates the page and the browser APIs; WASM does the heavy number-crunching.

The Compile Pipeline

The single most important mental model for WebAssembly is the pipeline: source languages → a compiler → a .wasm binary → the browser's virtual machine. Once you can picture this flow, everything else clicks into place.

The key insight: the "hard work" of translating human-friendly source into machine-friendly instructions happens once, at build time. JavaScript, by contrast, is delivered as text and must be parsed and just-in-time compiled by the browser every time the page loads. WebAssembly arrives pre-digested, which is a big part of why it starts fast and runs fast.

A brief history

WebAssembly grew out of earlier experiments to run fast code in the browser — Mozilla's asm.js (a strict, optimizable subset of JavaScript) and Google's Native Client. In 2015 the major browser vendors formed a community group, shipped a minimum viable product in 2017, and by 2019 WebAssembly was an official W3C recommendation with support in every mainstream browser. It is now a stable, standardized part of the web platform.

The Sandboxed Virtual Machine

When the browser loads a .wasm module, it runs the instructions on a small, well-defined virtual machine (VM). Understanding a few of its properties explains both why WASM is fast and why it is safe.

A stack-based machine

WebAssembly is stack-based: most instructions push values onto an operand stack or pop values off it. To add two numbers, you push the first, push the second, then run i32.add, which pops both and pushes the sum. This model is simple to validate and easy for the browser to translate into real machine code.

Linear memory: one big array of bytes

A WASM module gets a single, contiguous block of memory called linear memory — essentially a resizable ArrayBuffer. All of the module's data lives here, and crucially, JavaScript can see the exact same bytes through a typed array. This shared buffer is how larger data (like an image) crosses between the two worlds, a topic the next lesson explores in depth.

Sandboxed and deterministic by design

• Sandboxed — a module can only touch its own linear memory. It cannot read arbitrary browser memory, reach the file system, or call the network unless JavaScript explicitly hands it a function to do so. A malicious or buggy .wasm is contained.
• Structured control flow — there are no arbitrary "jump to any address" instructions. Branches are structured (blocks, loops, ifs), which lets the browser validate a module quickly and prove it is well-formed before running a single instruction.
• Deterministic — given the same inputs, a WASM module produces the same outputs on every machine, with the same integer and floating-point behavior. There are no surprising platform differences.

Binary & Text Formats

WebAssembly has two faces of the same thing. The binary format (.wasm) is what ships over the network. The text format (.wat, "WebAssembly Text") is a human-readable equivalent used for learning, debugging, and inspection. Tools like wat2wasm and wasm2wat convert between them.

The text format (.wat)

Here is a complete module that exports one function, add, taking two 32-bit integers and returning their sum. Read it top to bottom like a recipe:

(module
  ;; Define a function named $add that takes two i32 params
  ;; and returns one i32 result.
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a      ;; push parameter a onto the stack
    local.get $b      ;; push parameter b onto the stack
    i32.add)          ;; pop both, push a + b

  ;; Make $add callable from JavaScript under the name "add".
  (export "add" (func $add)))

Notice the stack machine at work: local.get pushes a value, and i32.add consumes the top two values and leaves the result. The final value on the stack becomes the return value.

The binary format (.wasm)

Compiled to binary, that same module is just a stream of bytes. Viewed as hexadecimal it looks like this — unreadable to us, but tiny and fast for the browser:

00 61 73 6d  01 00 00 00   ; "\0asm" magic + version 1
01 07 01 60  02 7f 7f 01    ; Type section: (i32, i32) -> i32
7f 03 02 01  00 07 07 01    ; Function + Export sections
03 61 64 64  00 00 0a 09    ; "add" export, code section begins
01 07 00 20  00 20 01 6a 0b ; body: local.get 0, local.get 1, i32.add, end

The first eight bytes are always the same: the magic number \0asm followed by the version. After that come sections that describe the module's types, functions, memory, imports, exports, and the actual code bodies. You never write these bytes by hand — the compiler does — but seeing them demystifies what "a binary format" really means.

WASM Alongside JavaScript

The whole point of WebAssembly on the web is that it complements JavaScript. Each does what it is best at. JavaScript owns the DOM, events, fetch, and the general glue of your app. WebAssembly owns the CPU-heavy inner loops. They call each other across a well-defined boundary.

Two directions of interop matter:

• JS calls WASM — after loading a module you get an instance.exports object. Its exported functions are ordinary-looking JavaScript functions that happen to run compiled code.
• WASM calls JS — you can hand the module an import object full of JavaScript functions. Since WASM has no DOM access of its own, this is how it reaches back out (for example, to log a value or touch the page).

// The simplest possible load-and-call in the browser.
// instantiateStreaming compiles the module *while it downloads*.
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('add.wasm')
);

// instance.exports.add is our compiled function.
console.log(instance.exports.add(40, 2)); // 42

Source Languages & Tooling

You reach WebAssembly through a language you already know or can learn quickly. The most common paths:

Rust: the ergonomic modern path

Rust has become the flagship WebAssembly language because wasm-bindgen automates the tedious marshalling. You write ordinary Rust; the tooling generates the JS glue that passes strings and structs across the boundary for you.

// lib.rs — a Rust function exported to JavaScript.
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn fibonacci(n: u32) -> u32 {
    if n <= 1 {
        return n;
    }
    let (mut a, mut b) = (0u32, 1u32);
    for _ in 2..=n {
        let next = a + b;   // iterative — no deep recursion needed
        a = b;
        b = next;
    }
    b
}

// Build with: wasm-pack build --target web
// wasm-pack emits a .wasm plus a JS module that wraps it.
import init, { fibonacci } from './pkg/my_module.js';

await init();                 // loads and instantiates the .wasm
console.log(fibonacci(10));   // 55

C with Emscripten

Emscripten is the veteran toolchain for C and C++. It can compile an entire game engine's worth of code, emitting a .wasm plus a JavaScript file that sets up memory and glue:

# fib.c compiled to WASM:
#   emcc fib.c -o fib.js -sEXPORTED_FUNCTIONS=_fibonacci -sEXPORTED_RUNTIME_METHODS=cwrap
#
# Then in the browser, load the generated fib.js which sets up
# Module, and call the wrapped function:
const fibonacci = Module.cwrap('fibonacci', 'number', ['number']);
console.log(fibonacci(10)); // 55

Beyond the Browser (WASI)

WebAssembly was born in the browser, but its portability and sandbox make it valuable everywhere. The WebAssembly System Interface (WASI) is a standard that lets a .wasm module request system capabilities — files, clocks, randomness — in a controlled, capability-based way outside the browser.

Because a WASI runtime grants only the capabilities you explicitly allow, WebAssembly has become popular for:

• Serverless and edge computing — modules start in microseconds and are isolated, so platforms run untrusted customer code close to users.
• Plugin systems — applications embed a WASM runtime to run third-party extensions safely inside a sandbox.
• Portable server workloads — one binary runs on any OS or chip with a compatible runtime.

Practice & Quiz

(module
  (func $calc (param $a i32) (param $b i32) (result i32)
    local.get $a     ;; stack: [a]
    local.get $b     ;; stack: [a, b]
    i32.sub          ;; stack: [a - b]
    local.get $b     ;; stack: [a - b, b]
    i32.mul)         ;; stack: [(a - b) * b]
  (export "calc" (func $calc)))

Best Practices & Pitfalls

✅ Do

• Reach for WASM when work is CPU-heavy: image/video, crypto, codecs, physics, simulation
• Keep JavaScript in charge of the DOM, events, and fetch — let it orchestrate
• Design your API so numbers cross the boundary and bulk data lives in shared memory
• Serve .wasm with the application/wasm MIME type so streaming compilation works
• Learn a little .wat to understand and debug, then let the compiler produce the binary

❌ Don't

• Reach for WASM for trivial or DOM-heavy tasks — the interop overhead can exceed the gain
• Expect WASM to touch the DOM or network on its own — it needs JS imports
• Assume WASM is always faster than JavaScript — measure before you commit
• Hand-write .wasm bytes — use a real toolchain (Emscripten, wasm-pack, AssemblyScript)

Summary

📚 Additional Resources

• WebAssembly.org — the official site
• MDN — WebAssembly Concepts
• The Rust and WebAssembly Book
• AssemblyScript — Introduction

🚀 What's Next?

Now that you understand what WebAssembly is, the next lesson gets hands-on: Using WASM in Web Apps — loading modules with instantiateStreaming, wiring up imports and exports, and marshalling strings and image data across shared linear memory.