5 exercises — Practice WebAssembly vocabulary in English: binary format, WASI, component model, runtimes, host functions, instantiation, and serverless WASM.
Core WebAssembly vocabulary clusters
Format: binary format (.wasm), WAT (WebAssembly Text), module, section (type, function, memory, export, import)
Execution: stack machine, linear memory, sandbox, instantiation, exports, imports, host function
WASI: WebAssembly System Interface, capability-based security, wasi_unstable, wasi_preview1, wasi_preview2
A platform engineer introduces WebAssembly to a backend team exploring new runtimes: "WebAssembly — WASM — is a binary instruction format designed as a portable compilation target. Write once in Rust, C, C++, Go, or Python; compile to WASM; run anywhere: browser, server, edge, embedded. The key property: sandboxed execution. A WASM module can't access the filesystem, network, or system calls unless explicitly granted. The module declares imports (what it needs from the host) and exports (what it exposes to the host). The host provides the imports — full control over what the module can do." What is a host function in WebAssembly, and why is the import/export model central to WASM's security?
Host function: a function provided by the host environment that a WASM module can call via its imports. Examples: console.log in the browser (the browser implements it, WASM calls it), filesystem read in a WASI runtime (the runtime implements it, the module calls it). Import/export model: WASM module declares what it needs (imports) and what it provides (exports). The host controls which imports are satisfied. If the host doesn't provide a filesystem import, the module literally cannot read files — the sandbox is enforced at the VM level, not by operating system permissions. WASM module structure vocabulary: Module: the fundamental unit — a .wasm binary file. Instantiation: creating a runnable instance from a module + imports. Multiple instances from one module. Import: a function, memory, table, or global that the module requires from the host. Export: a function, memory, table, or global that the module exposes to the host. Linear memory: a contiguous, resizable byte array. The module's heap. Host can read/write it. Stack machine: WASM's execution model. Instructions push/pop values from a virtual stack. Different from a register machine. WAT (WebAssembly Text format): human-readable .wat format. Compiles to .wasm binary. Useful for debugging. In conversation: 'The sandbox is why we can run user-submitted WASM plugins safely. They declare their imports; we provide a restricted set. No file access, no network — just our plugin API.'
2 / 5
A systems engineer explains WASI to a developer building a CLI tool: "WASM in the browser has access to browser APIs. But to use WASM outside the browser — on a server, in a CLI — you need system interfaces: files, network, environment variables. WASI — WebAssembly System Interface — standardises these. A WASM module compiled with WASI support can read files, write to stdout, get environment variables — but only the capabilities explicitly granted to it. It's capability-based security: you get a handle to a specific directory, not the whole filesystem. wasmtime and Wasmer both implement WASI." What is capability-based security in WASI, and how does it differ from traditional OS permissions?
Capability-based security: access is controlled by possessing a capability (an unforgeable reference/handle). In WASI: instead of "module X has read access to /tmp" (POSIX-style permission check), you pass the module a directory handle (preopened directory). The module can only access that specific directory — it has no way to reference any other directory. vs. traditional POSIX: POSIX checks permissions by process identity (UID/GID). Any path can be accessed if the process has permission. WASI checks by handle possession — no handle = no access, regardless of identity. WASI vocabulary: WASI preview1 (wasi_snapshot_preview1): the first widely-deployed WASI ABI. Supported by most toolchains and runtimes. Includes: fd_read, fd_write, path_open, clock_time_get, random_get. WASI preview2: a redesigned WASI using the component model. Async-first, cleaner API. Preopened directory: a directory the host grants the module access to at startup. Module can navigate within it. wasmtime: production WASM runtime by Bytecode Alliance (Mozilla, Intel, Fastly). Implements WASI and component model. Wasmer: alternative runtime with focus on multiple backends. WasmEdge: focus on cloud-native and edge computing. WAMR (WebAssembly Micro Runtime): embedded/IoT focus, minimal footprint. In conversation: 'WASI + capability-based security is why WASM is attractive for plugin systems. You give the plugin a handle to its own storage directory and our API — nothing else. Compared to a subprocess with broad OS access, it's a massive security improvement.'
3 / 5
A developer explains the WebAssembly Component Model to a team evaluating it for a plugin system: "The original WASM module model has a problem: the only data you can pass between modules is numbers (i32, i64, f32, f64) and linear memory. If you want to pass a string, you copy bytes into memory and pass a pointer — very low-level. The Component Model adds a type system on top: strings, lists, records, variants, resources. WIT — WebAssembly Interface Types — is the IDL (Interface Definition Language) for defining component interfaces. Components can import and export high-level interfaces, and the toolchain generates the glue code." What is the purpose of WIT in the WebAssembly Component Model?
WIT (WebAssembly Interface Types): a text-based IDL for declaring component interfaces. Defines: functions (with typed parameters and returns), records (structs), variants (enums with data), resources (object handles with methods), interfaces (named groups of functions), worlds (the complete set of imports and exports for a component). From a WIT file, toolchains generate bindings in: Rust (wit-bindgen), Python, JavaScript, Go. Why needed? Without WIT, two WASM components written in different languages can only communicate through linear memory (raw bytes) — the caller must know the exact memory layout. WIT makes the interface explicit and typed, enabling automatic binding generation. Component model vocabulary: Component: a higher-level WASM container that has WIT-typed imports/exports. Composed of one or more core modules. World: the complete interface of a component — what it imports (needs) and exports (provides). Interface: a named group of functions and types in WIT. Composition: combining multiple components by wiring their imports/exports together. wit-bindgen: tool that generates language bindings from WIT files. wasm-compose: tool for composing WASM components. WASI component model: WASI preview2 is built on the component model. In conversation: 'WIT is to WASM components what Protobuf is to gRPC — a language-agnostic contract that generates code on both sides.'
4 / 5
A performance engineer explains AOT vs. JIT compilation for WASM runtimes: "WASM bytecode is portable but must be compiled to native machine code before execution. There are two approaches. JIT (Just-In-Time): compile during execution. Faster startup than full compile, but compilation happens at runtime. AOT (Ahead-Of-Time): compile before execution to a native binary. Wasmtime supports both. AOT is critical for serverless WASM — cold start latency with AOT-compiled modules can be under 1ms, versus tens of milliseconds for JIT. The trade-off: AOT produces platform-specific binaries (x86-64 Linux) — you lose portability." What is a cold start in the context of serverless WASM, and why is WASM attractive for this use case?
Cold start: in serverless functions, a cold start is the first invocation after the function instance has been deallocated (idle timeout). The runtime must: pull the function code, initialise the execution environment, start the runtime, and then run the function. Container cold start: 500ms to several seconds. Python Lambda: ~100ms. Node.js Lambda: ~50ms. WASM cold start: Cloudflare Workers (V8 isolates, similar model) and Fastly Compute (WASM) achieve <1ms cold starts. Why: WASM modules are small (kilobytes to low megabytes), instantiation is cheap (no OS process spawning), the sandbox model reuses a single runtime process with many isolated instances. Serverless WASM vocabulary: Cloudflare Workers: edge compute platform using V8 isolates (JavaScript/WASM). Sub-millisecond cold starts. Fastly Compute: serverless WASM using wasmtime. Fermyon Spin: microservices framework on wasmtime + WASI. WasmCloud: distributed WASM actor model. Isolate: a lightweight sandboxed execution context. Cheaper than a process or container. AOT precompilation: in Wasmtime, use wasmtime compile to produce a .cwasm file. Can be instantiated in <1ms. Instant-on: the ideal of zero cold start latency with fresh sandboxes per request. WASM approaches this more than any other portable execution model. In conversation: 'We migrated an API gateway middleware to WASM. Cold starts went from 40ms (Lambda cold start) to under 1ms. For high-traffic APIs with bursty patterns, that difference is material.'
5 / 5
A compiler engineer explains WASM in the context of cross-language interoperability: "The original promise of WASM: compile any language to a portable binary, run anywhere. Today: Rust to WASM is excellent. C/C++ via Emscripten is mature. Go compiles to WASM but produces large binaries. Python via Pyodide bundles the Python interpreter as WASM. The Component Model is the next step: instead of a single monolithic WASM binary, you compose components written in different languages. A Rust component providing a parsing library can be called by a Python component without FFI complexity — the runtime handles the interface." What is Emscripten and what role does it play in the WASM ecosystem?
Emscripten: a complete open-source toolchain targeting WebAssembly (and asm.js). Uses LLVM + Clang as the compiler backend. Key feature: system library emulation. Emscripten implements POSIX functions (file I/O, pthreads, sockets) using browser or Node.js APIs. Real-world use: Figma (C++ render engine → WASM), Google Earth (C++ → WASM), AutoCAD Web (C++ → WASM), SQLite (compiled to WASM for browser use). Compile chain vocabulary: LLVM: compiler infrastructure. Clang compiles C/C++ to LLVM IR; LLVM emits WASM. wasm-pack: tool for building Rust-generated WASM for browser use. Generates npm package. wasm-bindgen: Rust library for calling JavaScript from WASM and vice versa. Pyodide: CPython compiled to WASM. Runs Python in the browser. Includes NumPy, Pandas. wasi-sdk: SDK for compiling C/C++ to WASM + WASI (for server-side/CLI use). Alternative to Emscripten when targeting WASI instead of browser. Binary format vocabulary: .wasm: binary format. Compact, fast to parse. .wat: text format. Human-readable S-expressions. Custom sections: non-functional sections in the binary for debug info (DWARF), component model metadata. Module validation: WASM spec requires structural validation before execution — type safety guaranteed at the binary level. In conversation: 'Emscripten is how we ported 500K lines of C++ simulation code to the browser. The alternative was a rewrite — Emscripten saved 18 months of work.'