Wasm Components

[tomassedovic]

Metadata
Point of contact	@yoshuawuyts
Team(s)	compiler, lang, libs
Goal document	2026/wasm-components

Summary

In 2026 we want to improve the state of Wasm Component support in Rust. This
means adding and stabilizing three new compiler targets, as well as begin
experimentation with Wasm-specific language features.

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@yoshuawuyts
Team(s)	compiler, lang, libs
Goal document	2026/wasm-components

Summary

In 2026 we want to improve the state of Wasm Component support in Rust. This
means adding and stabilizing three new compiler targets, as well as begin
experimentation with Wasm-specific language features.

Tasks and status

[tomassedovic]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[yoshuawuyts]

Update 2026-05-27

We had a meeting between T-Compiler and the Wasm Components Project goal at the Rust All-Hands last week. The meeting notes can be found here.

We discussed the upcoming LLVM 23 rev and merge window into rustc, ABI changes (both threading and multi-value), WASI 1.0, and the wasm32-web-component target. In all cases we seem to be one the same page now, which was the intended outcome of the meeting.

On the WASI 0.3 side: the spec will likely be put up for a vote in the next few weeks as we now have two working impls. This will unblock the wasm32-wasip3 target in the compiler from being brought up to tier 2. Though as discussed in the meeting we will want to hold off on that until we can pull in LLVM 23. The work on the rest of the project goals will start after that's done.

[yoshuawuyts]

Update 2026-06-15

Goal update

WASI 0.3 has officially been released and we’ve published a blog post about it over on the Bytecode Alliance blog. The necessary ABI changes have also landed in LLVM upstream, and will be part of the LLVM 23 release. With both requirements now in place, @alexcrichton has filed rust-lang/compiler-team#1001 to start the process to promote the wasm32-wasip3 target to tier 2.

Once the wasm32-wasip3 target is tier 2, we’ll kick off work on the remaining work items: the no-std -component target, the -web target, and eventually updating the wasip3 target with std::thread support. All of these depended on WASI 0.3 launching, and wasm32-wasip3 reaching tier 2 - which we’re now close to.

Other noteworthy items

Not tracked as part of the goals here, but still worth mentioning as it’s related to the work we’re doing here:

• Wasmtime 47 will release in July and will have WASI 0.3 support enabled by default.
• @Mark-Simulacrum has opened a PR on rust-lang/rust to compile proc macros to Wasm Components and run them in a Wasmtime-based sandbox: Implement support for proc macros on wasm32-wasip2 rust#157590
• I’m currently finishing work for the wstd runtime to support WASI 0.3, ensuring it will be compatible by the time we’re ready to land wasm32-wasip3 as tier 2.
• After conversations with @Darksonn at the all-hands, @alexcrichton has started work on adding epoll support to wasi-libc to enable mio and tokio to compile on wasm32-wasip3.

Browser support update

Last week the Bytecode Alliance also published a blog post (The Road to Component Model 1.0) that I thought contained a particularly good quote:

Both Mozilla and Chrome are paying attention. The Mozilla team presented performance results at a recent in-person WebAssembly CG meeting, and Ryan Hunt discussed Mozilla’s Component Model work in a recent blog. The Chrome V8 team opened an issue for evaluating Component Model implementation. These aren’t commitments, but they’re meaningful signals.

My plan is that once we land a native -web target in Rust, to work with the Mozilla team on a demo showing Rust compiling directly to Wasm Components and running that natively in the browser - no shims needed. I think that will make for a really good demo; it's something that a lot of people have been wanting to see for a very long time.

[yoshuawuyts]

Update 2026-07-14

Not much to report this month. Main highlights:

• Promote wasm32-wasip3 to Tier 2 compiler-team#1001 is now in FCP
• The LLVM changes are still on track to being released as part of LLVM 23. We're now waiting for LLVM to cut a release candidate and for Rust to start pulling it down to begin testing out the changes end-to-end.
• We expect cooperative multi-threading in Wasm Components to be stabilized in WASI 0.3.3, which is scheduled for December 2026. The plan is for Rust to support this experimentally before then, and use it as part of the validation before the feature is stabilized.

[yoshuawuyts]

Update 2028-08-28

I confirmed with Alex this week that all the necessary LLVM patches have landed before the LLVM 23 branch date. That means we should be on track for bringing wasm32-wasip3 to tier 2 either in Rust 100 (Nov 13th 2026) or Rust 101 (Dec 24th 2026). As well as on track for the inclusion of cooperative multi-threading as a component-model dependency for WASI either in WASI 0.3.3 (Dec 8th 2026) or WASI 0.3.4 (Feb 2027).
 
The timeline for multi-threading is based on the assuming that we can land an implementation in the Jco runtime by then. Adding coop threading to the Rust target (e.g. std::thread support) will happen at some later point, after we've shipped it in WASI (~April 2027 most likely at the soonest on Rust stable).

The final possible wrinkle in all this is that we have not yet tested everything end-to-end yet, so these timelines are assuming that integration into WASI-libc and the Rust target don't surface any major issues. We expect they won't, but there is always the possibility we have missed something we won't catch until later.