WebAssembly Runtime Vocabulary: WASM, WASI, and the Component Model

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

1. “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.”
2. “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.”
3. “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.”
4. “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.”
5. “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.

Navigating Nuances: A Practical Look at Terminology

Let’s be honest – sometimes the most challenging aspect of learning a new technology isn’t the what, but the how we talk about it. As WebAssembly runtime engineers, you’ll frequently encounter specific terminology related to WASI and the Component Model that might feel unfamiliar when spoken or written in professional contexts. It’s not just about knowing the definitions; it’s about conveying your ideas clearly and effectively, which is crucial for code reviews, team discussions, and documentation.

Consider this scenario: You’re reviewing a pull request where a developer has implemented a new feature using WASI. A comment appears in the review: “This instantiation seems overly complex – could we simplify it by leveraging the linear memory directly instead of going through the WASI interface?” This isn’t just about whether the code works; it’s about articulating your understanding of the tradeoffs involved, referencing specific concepts like “instantiation,” “linear memory,” and the potential need for a more direct approach. Similarly, in a Slack channel discussing performance, you might hear someone say, “The WASI filesystem access is causing a bottleneck; we should investigate optimization strategies.” This requires familiarity with how WASI handles file system interactions and the implications for runtime performance – vocabulary centered around “WASI” itself.

Another common situation arises when describing your work in a pull request description: “This component utilizes WASI’s standard input/output stream to communicate with the host application, facilitating data exchange based on the Component Model’s defined interfaces.” Notice the emphasis on interfaces and how they relate to communication – key elements within the broader understanding of the Component Model. Mastering these terms will improve your ability to collaborate effectively with other engineers and contribute meaningfully to technical discussions. Don’t be afraid to ask for clarification; a quick question about “WASI” versus “linear memory” can save you hours of confusion later on. Ultimately, clear communication is built upon a solid understanding of the core vocabulary.

Finally, remember that precision matters in engineering documentation and design proposals. When outlining requirements for a new WASI feature, stating it needs “direct access to linear memory” will be far more effective than simply saying “it should be fast.”

Here’s an example of how you might use wasi-sdk to inspect the available memory layout:

wasi-sdk --meminfo

This command, executed in a development environment, provides detailed information about the linear memory regions accessible within the WASM runtime. Understanding this output – terms like “region size,” “offset,” and “flags” – is crucial for discussions around memory management and optimization. It’s a practical demonstration of how these abstract concepts translate into tangible data.