WebAssembly Runtime Vocabulary: WASM, WASI, and the Component Model
Master the English vocabulary for WebAssembly runtime engineering — instantiation, linear memory, WASI, the Component Model, and WIT interface types for WASM engineers.
WebAssembly’s Vocabulary Is Still Evolving
WebAssembly is a young and fast-moving technology. Its vocabulary is drawn from multiple traditions — virtual machine design, systems programming, and web standards — and new terms are introduced with each new proposal. For engineers working on WASM runtimes or applications, staying current with the terminology is part of staying current with the ecosystem.
This guide covers the essential English vocabulary for WASM runtime engineers, from the core execution model through WASI and the Component Model.
Core WASM Execution Vocabulary
| Term | Definition |
|---|---|
| Module | A compiled WebAssembly binary — a stateless, loadable unit of code and data |
| Instance | A running module with its own memory, table, and global state |
| Instantiation | The process of creating an instance from a module, resolving imports and allocating resources |
| Linear memory | The flat, resizable byte array that a WASM instance uses as its heap |
| Memory page | The unit of memory growth in WASM: 64 KiB; memory is grown one page at a time |
| Table | A typed array of references (typically function references) in a WASM module |
| Import | An external value (function, memory, table, or global) that a module requires from the host |
| Export | A value (function, memory, table, or global) that a module exposes to the host or other modules |
| Host function | A function implemented outside WASM (by the runtime or the embedding application) and imported into a module |
| Trap | A runtime error that terminates execution of a WASM module — the WASM equivalent of a panic or segfault |
Traps occur for a defined set of reasons: unreachable instruction, division by zero, out-of-bounds memory access, type mismatch, or stack overflow. Unlike exceptions, traps are unrecoverable by the WASM module itself — the runtime handles them.
WASI Vocabulary
The WebAssembly System Interface (WASI) is a set of standardised APIs that allow WASM modules to interact with the operating system in a portable way.
| Term | Definition |
|---|---|
| WASI | WebAssembly System Interface — a capability-based API for system access from WASM |
| Capability | A token that grants a WASM module access to a specific resource (a file, a socket, etc.) |
| Preopened directory | A directory that the host grants the WASM module access to before execution begins |
| WASI Preview 1 | The original WASI specification (unstable), based on POSIX-like file descriptor APIs |
| WASI Preview 2 | The stable, Component Model-based version of WASI, using the WIT interface definition language |
| Snapshot | An earlier version of the WASI specification (used informally in the Preview 1 era) |
| Sandboxing | The isolation guarantees that prevent a WASM module from accessing resources it has not been granted |
WASI’s capability model differs from traditional POSIX in an important way: a WASM module cannot access the file system or network unless the host explicitly grants it a capability. This is a key selling point for security-sensitive deployments.
Component Model Vocabulary
The WASM Component Model is a proposal that extends the core WASM format to support higher-level composition and language interoperability.
| Term | Definition |
|---|---|
| Component | A higher-level WASM unit that encapsulates one or more core modules with typed interfaces |
| WIT (WebAssembly Interface Types) | The interface definition language used to describe component interfaces |
| World | A WIT concept that defines the imports and exports of a component — its complete interface contract |
| Interface | A named, typed collection of functions defined in WIT |
| Canonical ABI | The calling convention that defines how high-level WIT types are lowered to and lifted from core WASM values |
| Lifting | Converting core WASM values into high-level Component Model types |
| Lowering | Converting high-level Component Model types into core WASM values |
| Linking | Composing multiple components by connecting their imports to other components’ exports |
| Registry | A service for distributing and discovering WASM components (analogous to npm or cargo) |
Runtime and Toolchain Vocabulary
| Term | Definition |
|---|---|
| Wasmtime | A production WASM runtime maintained by the Bytecode Alliance |
| Wasmer | An alternative WASM runtime with support for multiple embedding languages |
| wasm-bindgen | A Rust tool that generates bindings between WASM modules and JavaScript |
| wit-bindgen | A tool that generates language bindings from WIT interface definitions |
| AOT compilation | Ahead-of-time compilation — compiling WASM bytecode to native machine code before execution |
| JIT compilation | Just-in-time compilation — compiling WASM bytecode to native code at runtime |
| Interpreted execution | Running WASM bytecode directly without native compilation — slower but faster to start |
| Fuel | A mechanism in some runtimes (e.g., Wasmtime) that limits the number of WASM instructions a module can execute |
Example Sentences
- “The instantiation of this module fails because the host is not providing the required WASI preopened directory capability — the sandbox configuration needs to be updated.”
- “Linear memory access is bounds-checked at runtime; an out-of-bounds access will trap rather than corrupt adjacent memory, which is a key safety guarantee of the WASM execution model.”
- “We are migrating from WASI Preview 1 to Preview 2 so that we can define our plugin interfaces using WIT and benefit from the canonical ABI for cross-language interoperability.”
- “The Component Model’s lifting and lowering mechanism handles string encoding differences between Rust and JavaScript automatically — we no longer need manual wasm-bindgen annotations for string arguments.”
- “We use AOT compilation in production for predictable startup latency, but retain the JIT fallback for architectures we have not yet generated native targets for.”
Common Mistakes in WASM Vocabulary
“WASM module” and “WASM component” are not interchangeable in the Component Model world. A module is a core WASM artefact; a component is a higher-level, typed unit. Using these terms correctly signals familiarity with the current specification.
“Sandbox” is often used loosely. In WASM, the sandbox guarantee is specific: memory isolation (no access beyond linear memory) and capability-based resource access (no implicit OS access). When discussing WASM security, be precise about which sandbox properties you are relying on.