A Wasm component is a wrapper around one or more Wasm modules that exposes and consumes explicit interfaces. It lifts core Wasm values into richer types and lowers them back for execution, so separately built code can communicate without a custom linear-memory contract. section 3.5 section 4.0
Components are designed for composition: a binary component can import a function that a library component exports, then link the pair into one .wasm artifact. WIT describes the imports, exports, and worlds that must match; language toolchains generate the cross-language glue. section 4.5 section 3.2.3
The component model changes portability and isolation in practical ways:
- Link implementations written in different languages, avoiding a separate microservice, network stack, and JSON serialization solely for cross-language calls. section 3.1.1
- Keep each component's memory isolated; exchange values through imports and exports instead of shared memory. Opaque resources cross the boundary as handles. section 3.1.2
- Limit a component to declared imports, then replace and relink a patched dependency without rebuilding unchanged business logic. section 3.1.3
JavaScript guest, Python host
Define a greet function in WIT, implement it in JavaScript, and componentize it with jco into greet.wasm. A Python host embedding Wasmtime can load that component and call the JavaScript function. This proves the boundary works, but hand-writing WIT and hosts can be cumbersome; standardized interfaces and generic hosts reduce that work. section 3.2.3 section 3.3.3
Components can also use host capabilities through WASI. WASI 0.2 defines WIT worlds such as a CLI command and an HTTP proxy, while a host decides which capabilities—such as standard output—are available. Wrapping an existing module creates a component, but does not by itself add Preview 2 APIs. section 4.1 section 4.2 section 4.3
Figure 4.2 Comparing how data flows in chapter 2’s Wasm module example versus using Wasm components. The top diagram shows the manual setup, with a custom contract between the module and a custom host. The bottom diagram shows how components rely on WebAssembly Interface Types (WIT) and the Canonical ABI, making it possible to interact with a potentially generic host without custom wiring.
Compare manual module-memory wiring with component communication through WIT and the Canonical ABI. section 4.0
