How the WebAssembly Component Model Connects Separate Modules

Core Wasm stops at numbers. It defines stateless, sandboxed WebAssembly binaries and a compact instruction set, but it does not prescribe how two assembly modules should represent a string, record, variant, list, error, or long-lived resource.

That omission is deliberate. Core WebAssembly functions exchange primitive values such as i32, i64, f32, and f64, while linear memory is merely bytes addressed by integers. A programming language may place a string's pointer and length in two parameters; another toolchain may use a structure in memory. Both modules remain valid, yet neither automatically understands the other's assembly interface.

The same problem appears around the operating system. Core Wasm does not grant filesystem or network access, nor does it define a universal system interface. A host chooses imports, implements them, and decides which capabilities an instance receives. WASI standardizes many such interfaces, but WASI alone does not solve high-level data exchange or composition between independently produced components.

This boundary matters. A module can deliver near-native execution speed and strong memory isolation while still lacking a compatible application-level contract with its neighbor. Sandboxing answers what code may touch. It does not answer what an imported function means.

Adapters do the translation. The canonical ABI lowers high-level interface types into Core Wasm values and memory operations, then lifts the returned representation into the type expected by the caller.

Suppose a Rust component exports a function accepting a string and a Python component imports it. Their native runtimes need not share an object layout, garbage collector, or allocator because the canonical ABI specifies the transfer conventions, including where bytes live, how lengths travel, and which side performs cleanup. The current WebAssembly Component Model specification↗ defines this machinery rather than requiring every pair of toolchains to invent a private bridge.

WIT provides the contract. WebAssembly Interface Types, usually stored in .wit files, describe records, variants, enums, flags, lists, options, results, functions, and interfaces without choosing Rust, Python, JavaScript, or another programming language. Bindgen tooling turns that language-neutral description into bindings for each side.

Resources cover stateful handles. A database connection or open file cannot sensibly cross the boundary as raw in-memory bytes, so a resource is represented by an opaque handle whose methods and lifetime remain controlled by the component that owns it. This reduces accidental coupling and prevents a consumer from depending on the provider's internal memory layout.

The cost is real. Lowering and lifting can allocate memory, copy strings or lists, and add processing around a call, so a chatty component boundary may lose performance compared with one coarse function that moves the same data once. Treat the boundary like an RPC interface, even when both components run inside one process.

Composition matches typed interfaces. A composer or runtime connects an export to a compatible import, while adapters reconcile Core Wasm calling conventions beneath the high-level contract.

That makes the model a system that facilitates interactions between individual units of WebAssembly code built at different times and in different languages, provided their WIT worlds agree. A world names the interfaces a component imports and exports. It is closer to a package boundary than a C header because capabilities and resource ownership are visible in the type system.

Versioning remains the hard part. The model can determine that two interfaces differ, but it cannot decide whether changing record user or adding a required function preserves the behavior applications expect. Package names and semantic versions help toolchains select definitions; maintainers still need compatibility policy and adapters for significant changes.

The Lego-brick analogy is useful only up to a point. Components are not automatically interchangeable just because both are Wasm: their interface names, types, semantics, and dependencies must line up, and an adapter cannot repair contradictory meanings. The official component-model documentation↗ shows composition around explicit WIT contracts rather than arbitrary module plugging.

Composition also narrows authority. If an image-processing component imports only a byte stream and exports pixels, the host need not expose a filesystem interface WASI implementation at all. That capability-oriented design reduces the damage available to code with vulnerabilities, although it does not make the component's own logic correct.

Wasmtime instantiates the graph. It validates the component, resolves its typed imports, generates or selects adapters, and executes the resulting Core Wasm instances under host-supplied capabilities.

The distinction matters because a component is not a new processor instruction format replacing Core Wasm; it is a packaging, typing, and composition layer whose implementation eventually reaches ordinary modules and host functions. The runtime handles canonical ABI details that application developers should not reproduce by hand.

A practical path looks like this:

1. Define the imported and exported interfaces in WIT.
2. Generate guest bindings with a language toolchain that supports components.
3. Compile the guest into a component, sometimes by wrapping an existing Core Wasm module with adapter metadata.
4. Configure the host with the WASI functions and other capabilities the component imports.
5. Instantiate the component and call its typed exports through generated host bindings.

Do not skip the WIT review. A successful build proves type compatibility, not sensible granularity, stable error behavior, or acceptable copying costs. Large lists crossing repeatedly can turn adapter work into the dominant expense.

Wasmtime is the reference-quality runtime most developers encounter, but browser support is a separate question. Browsers broadly execute Core Wasm; direct, stable browser APIs for arbitrary components have not become the universal deployment baseline. A web application may instead use generated JavaScript bindings and transpilation around component functionality. The Wasmtime project↗ and the Bytecode Alliance repository↗ track the runtime implementation and supported component APIs.