Bytecode Alliance maps the Component Model 1.0 path

The Bytecode Alliance outlines five workstreams needed to ship a stable Component Model 1.0.

WASI P3 is close, and this roadmap shows what still has to land before Component Model 1.0 can be called stable: five workstreams, one browser target, and a compatibility plan built around existing P1 and P2 deployments.

Item	What changes	Why it matters
ABI improvements	Lazy values, multivalue returns, error context	Less copying and better sync-call performance
Browser path	Native support in at least two engines	Performance and broader adoption signals
Implementation ease	Simpler spec plus guest and host C ABIs	Lower the cost of building support
Ecosystem growth	Docs, language support, tooling, debugging	Make the stack usable in practice
Expressivity gaps	WIT features like optional imports	Close real-world API design gaps

1. ABI improvements

The biggest technical change in the roadmap is the ABI itself. Today, components rely on cabi_realloc and host-driven allocation, which works but creates friction around fragmentation, failure handling, and extra calls for values like string lists.

The planned replacement is a lazy value model: the callee returns opaque handles, and the caller materializes them only when needed. That should reduce copying, support zero-copy forwarding, and move some string handling out of the engine and into guest code.

• Opt-in lazy ABI in a 0.3.x release
• Adapter support for old eager components
• Multivalue returns at the C ABI level
• Error context attached to failures
• Separate GC ABI option for GC-based languages

There is also a performance target tied to this work: zero overhead for synchronous component-to-component calls. Current async task machinery adds overhead even on sync paths, so the plan is to make synchronous adapters cheaper after WASI P3 ships.

2. The browser path

Component Model 1.0 needs native implementation in at least two browser engines. Today, jco can transpile components into core Wasm plus JavaScript glue, so components already run in browsers without native support.

Native support still matters because it can cut out the glue layer and improve real workloads. Mozilla’s experiments on DOM-heavy Wasm code point to nearly 2x speedups in some cases, and the browser vendors are paying attention through telemetry and active evaluation.

• jco emits a “use components” signal for telemetry
• Mozilla has shared performance results with the WebAssembly CG
• Chrome’s V8 team has opened an evaluation issue
• Native support would help browser and non-browser Wasm adoption

The browser story is not just about speed. It also creates proof that the model fits real web workloads, which in turn gives language and framework teams a reason to support it upstream.

3. Making implementation easier

The roadmap also tries to shrink the work required to implement the spec. One move is to keep only the “good parts” of the current P3 spec in 1.0, instead of forcing implementers to carry every transitional detail forward.

Another move is to define guest and host C ABIs, generated from wit-bindgen. Guest toolchains can target a core Wasm module, then package it as a component; host runtimes can use a simpler entry point instead of reimplementing the full spec from scratch.

guest -> core wasm -> wasm-component-ld -> component host runtime -> generated host C ABI -> component

A proposed tool called lower-components would also “smash” multi-module components into a single core Wasm module with the same behavior. That gives runtime authors another path to support the model without starting from the hardest possible implementation.

4. Growing the ecosystem

Even a clean spec will not matter if developers cannot use it. So the roadmap includes a sustained push on docs, language support, and tooling. The goal is to make Component Model workflows feel normal across languages, not just in a few experimental projects.

Some of that work is already visible in the ecosystem. Rust, Tokio, LLVM, and CPython have early steps underway, while tools like jco, wac, and wkg cover browser glue, composition, and package publishing.

• More tutorials and reference docs for each language
• Upstream P3 support in major language ecosystems
• Composition and registry tooling for components
• Record/replay debugging using WAVE traces

Yan Chen’s demo is a good example of where the ecosystem could go next: instrumented components can record WIT-level calls, replay them later, and even edit traces by hand. That kind of debugging is hard to get in shared-state systems and much easier in a shared-nothing model.

5. Closing expressivity gaps

The last workstream is about WIT, the interface language that describes what components import and export. Real users have already found places where the language needs more expressive power, so 1.0 has to address those gaps instead of freezing them in place.

One example is optional imports, which let a component declare that it can work with a minimal host world and only use extra capabilities when they exist. That matters for libraries and portable apps that should not hard-code every possible system service.

• Optional imports for capability-aware components
• More WIT features based on real usage
• Better support for portable standard libraries
• Cleaner API design across hosts with different capabilities

This is the quiet part of the roadmap, but it shapes how pleasant the model will be to use. If WIT is too rigid, the whole stack becomes harder to adopt; if it grows in the right places, components can stay portable without giving up useful host integration.

How to decide

If you are a runtime or compiler engineer, start with ABI improvements and implementation-easing work. If you are building browser integrations, the browser path is the signal to watch. If you ship libraries, tooling, or docs, the ecosystem section is where the adoption story will be won.

For most readers, the key point is simple: Component Model 1.0 is not a single feature drop. It is a coordinated set of changes that aims to keep today’s components working while making the next generation easier to build, faster to run, and simpler to ship.