WebAssembly Interface Types (WIT): English Vocabulary for Component Model Discussions

The WebAssembly Component Model and its Interface Definition Language, WIT, represent one of the most significant shifts in how developers think about language interoperability. If you’re working on Wasm components, contributing to wasmCloud, or evaluating WASI-based runtimes, you need precise English vocabulary to participate in architecture discussions. This guide covers the terms that appear most often in WIT and Component Model conversations.

Core Vocabulary

WIT IDL (Interface Definition Language) The textual format used to define the types, interfaces, and worlds that WebAssembly components expose and consume. WIT files have the .wit extension and describe contracts in a language-neutral way.

“Before we start implementing in Rust, let’s agree on the WIT IDL first — once both sides code to the same interface definition, integration becomes straightforward.”

Interface A named set of functions and types in WIT that a component can either provide (export) or consume (import). An interface is analogous to a trait or protocol in a programming language.

“We defined a logging interface in WIT so that any component in our system can emit structured log events without knowing which backend handles them.”

World A WIT construct that describes a complete execution environment for a component: which interfaces it imports from the host or other components, and which interfaces it exports as its public surface.

“The component’s world imports the filesystem and HTTP interfaces from the host but only exports a single process function — that’s the whole public API.”

Component A compiled WebAssembly unit that implements a specific world. A component has a well-defined interface boundary and can be composed with other components without knowing their implementation language.

“We built the PDF rendering component in C++ and the data processing component in Rust — they compose cleanly because both implement the same world definition.”

Resource type A WIT type that represents an opaque, handle-based value — similar to a file descriptor. Resources are owned and can be passed between components without exposing their internal structure.

“The database connection is modelled as a resource type in WIT, which means the host manages the lifecycle and the component only holds a handle.”

Canonical ABI The standard binary encoding that defines how values of WIT types are represented when they cross component boundaries. The canonical ABI handles the lifting and lowering of values between different memory representations.

“We hit a bug where strings weren’t being lowered correctly across the component boundary — it turned out we’d misread the canonical ABI spec for list types.”

Composition The process of linking two or more components together by matching their imports and exports. Composition happens at build time using tools like wasm-compose and creates a new, combined component.

“The beauty of composition is that neither component needs to know the other’s implementation language — they only need compatible WIT interfaces.”

Import vs export in WIT context In WIT, a world’s imports are what the component needs from its environment, and its exports are what the component provides to the outside world. This is the opposite direction from many dependency systems.

“Remember that imports are what the component consumes and exports are what it offers — I always have to remind myself that it’s from the component’s point of view, not the caller’s.”

Key Collocations

• define a WIT interface — “Let’s define a WIT interface for the authentication service before we split the work between teams.”
• implement a world — “The component needs to implement the full world, including all the required exports — missing any one will fail validation.”
• compose components — “We can compose components written in different languages as long as their interfaces match the WIT contract.”
• lift and lower values — “The canonical ABI specifies how to lift and lower values at each component boundary — this is where encoding bugs usually hide.”
• publish to a registry — “Once the component passes our integration tests, we publish it to the OCI registry so other teams can pull it as a dependency.”
• target a platform — “When we target a WASI platform, the world we implement must match the WASI interfaces that platform exposes.”

Using This Vocabulary in Design Discussions

WIT discussions often involve clarifying the direction of a relationship. In most API discussions, we say “the client calls the server.” In WIT discussions, we use the frame of imports and exports: “the component imports the HTTP interface and exports the handler.” This takes some getting used to, especially because the direction is from the component’s perspective.

A useful pattern for explaining composition to newcomers is the analogy: “Think of WIT interfaces like USB ports. If two components have matching ports — one exports what the other imports — they can be plugged together without knowing what’s inside either device.”

When discussing the canonical ABI in code reviews, the verbs lift and lower are standard. Lifting means reading a value from Wasm linear memory into a host-side representation. Lowering means writing a host-side value into Wasm memory. You will see these in error messages and PR discussions: “The string is lowered into the component’s memory before the function is called.”

Common Mistakes to Avoid

A frequent confusion is between module (the old Wasm term for a compiled binary unit) and component (the new Component Model term). Components are built from modules but have a richer interface system. In Component Model discussions, using “module” when you mean “component” signals unfamiliarity with the newer standard.

Another mistake is describing WIT interfaces as “classes.” They are closer to traits or protocols — they define behaviour without implementation. Saying “we defined a WIT class” will confuse experienced Wasm engineers.

Practice Tip

Read a public WIT file — the WASI HTTP or WASI filesystem definitions are good starting points — and try to describe what you see in plain English sentences: “This world imports X and exports Y. The interface provides functions for doing Z.” This translation exercise builds the fluency you need to explain WIT to colleagues who are encountering it for the first time.