Awesome Wasm Components
May 6, 2026 · View on GitHub
A curated list of WebAssembly Component tooling and ready-to-use components.
What are Wasm Components?
WebAssembly (Wasm) Components are a typed package format that packages core Wasm Instructions into typed libraries and binaries. Wasm Components are also used by the Wasm System Interface (WASI) to create standard interfaces for various environments.
Without a standard package format every language, toolchain, and platform has to define their own way of packaging up Wasm instructions. WebAssembly Components standardize this, enabling tools, languages, and platforms to all natively interoperate with each other.
Wasm Components follow a structure that is very similar to other platforms, here is how they compare:
| WebAssembly | Linux | Windows | macOS | |
|---|---|---|---|---|
| Instruction Format | Core Wasm | x86, ARM, etc. | x86, ARM | ARM |
| Container Format | Wasm Components | Executable and Linkable Format (ELF) | Portable Executable (PE) | Mach-O |
| Interface Definition Language | Wasm Interface Types (WIT) | C header files | Windows Metadata (WinMD) | (Objective-)C header files + Mach IDL + Swift Modules |
| System Interfaces | Wasm System Interface (WASI) | POSIX + Linux User-Space APIs | Win32 + UWP | POSIX + Darwin Syscalls |
Note
WASI 0.1 was released in late 2019 and was exclusively designed for UNIX-like environments. That meant that all the work put into WASI couldn't be reused for the web and other environments. Wasm Components were released in early 2023 together with WASI 0.2, which is entirely portable across environments.
WASI 0.3 is planned for the end of 2025, using the newly added native async support in Wasm Components. This will enable components with async interfaces to directly link to each other. WASI 0.2 was a big departure from WASI 0.1. WASI 0.3 will be a relatively small iteration of WASI 0.2.
Tools
Programming Language Support
These languages can be compiled to Wasm Components. Some languages have first-party support for Wasm Components, while other languages rely on externally maintained tools.
| Language | Name | WASI Version | Maintained By | Notes |
|---|---|---|---|---|
| C and C++ | wasi-sdk | 0.2 + 0.3 | W3C Wasm CG | 0.3 is in-progress |
| C# | componentize-dotnet | 0.2 | Bytecode Alliance | |
| Go | go-modules | 0.2 | Bytecode Alliance | |
| Java | graal | - | Oracle | Planned - Tracking Issue, Roadmap |
| JavaScript and TypeScript | jco | 0.2 | Bytecode Alliance | |
| JavaScript | componentize-qjs | 0.2 + 0.3 | Tomasz Andrzejak | |
| Kotlin | Kotlin | 0.2 | JetBrains | |
| Python | componentize-py | 0.2 | Bytecode Alliance | |
| Python | cpython | 0.2 | Python | In-progress |
| Ruby | ruby.wasm | 0.2 | Ruby | In-progress |
| Rust | wasm32-wasip2 compiler target | 0.2 + 0.3 | Rust Project | 0.2 Introduction, 0.2 Stabilization, 0.3 is planned |
| Swift | Swift | 0.2 | Swift | Planned - Roadmap Accepted |
Bindings Generators
Being able to compile a language to Wasm Components is a good first step, but it’s also important to be able to make function calls. Most languages don’t yet provide a native way to call Wasm functions, so the second best option is to use bindings generators that can generate those calls for you.
| From | To | Name |
|---|---|---|
| Wasm Interface Types | C and C++ | wit-bindgen c |
| Wasm Interface Types | C# | wit-bindgen csharp |
| Wasm Interface Types | JSON Schema | component2json |
| Wasm Interface Types | Markdown | wit-bindgen markdown |
| Wasm Interface Types | Moonbit | wit-bindgen moonbit |
| Wasm Interface Types | Rust | wit-bindgen rust |
| WebIDL | Wasm Interface Types | webidl2wit |
Host Runtimes
Host runtimes can take Wasm Components and execute them. Runtimes can either be loaded as language-native libraries, run as standalone binaries, or be hosted by third party providers:
| Kind | Name | WASI Version | Maintained By | Notes |
|---|---|---|---|---|
| AI Agent Platform | Noorle | 0.2 | Noorle | Plugin system |
| AI Agent Runtime | Capsule | 0.2 | Mohamed Diallo | |
| Bazel Extension | WebAssembly Component Rules | 0.2 | Pulse Engine | |
| Browser | Google Chrome | - | Wasm Component model under evaluation | |
| Buck2 Extension | Wasmono | 0.2 + 0.3 | Tomasz Andrzejak | |
| Build System | MS Build | 0.2 | Microsoft | Proposed |
| C Library | Wasmtime crate | 0.2 + 0.3 | Bytecode Alliance | 0.3 support in-progress |
| Command Line | Wasmtime | 0.2 + 0.3 | Bytecode Alliance | 0.3 support in-progress |
| Command Line | zwasm | 0.2 | ClojureWasm | |
| Durable Compute | Golem | 0.2 | Golem Cloud | |
| Durable Compute | Obelisk | 0.2 | Obelisk | |
| Edge Compute | Edgee | 0.2 | Edgee | |
| Edge Compute | Fastly Edge Compute | 0.2 | Fastly | |
| Editor | VS Code | 0.2 | Microsoft | Plugin system |
| Editor | Zed | 0.2 | Zed Industries | Plugin system |
| Go Library | Gravity | 0.2 | Arcjet | In-progress |
| GraphQL Platform | Grafbase | 0.2 | Grafbase | Plugin system |
| Hypervisor Guest | Hyperlight Wasm | 0.2 | CNCF | 0.2 async APIs in-progress |
| Kubernetes | SpinKube | 0.2 | CNCF | |
| Kubernetes | WasmCloud | 0.2 | CNCF | |
| MCP Server | WasMCP | 0.2 | WasMCP | |
| MCP Server | Wassette | 0.2 | Microsoft | |
| Node.js + Web | Jco | 0.2 + 0.3 | Bytecode Alliance | 0.3 support in-progress |
| Rust Library | Wasmtime crate | 0.2 + 0.3 | Bytecode Alliance | 0.3 support in-progress |
| Serverless Runtime | Spin | 0.2 | CNCF | |
| Web Framework | Leptos | 0.2 | Leptos | Plugin system |
Registries
Wasm Components can be uploaded to any OCI v1.1-compatible registry, using the Wasm OCI Artifact Layout. The following registries support pushing and pulling Wasm Components:
Tip
Pulling Wasm Components from OCI Registries
To download a .wasm application, library, or interface from an OCI registry we want to use wkg.
With it we can download Wasm Components from OCI URLs:
$ wkg oci pull ghcr.io/yoshuawuyts/fetch:latest -o fetch.wasm
Components
Applications
Wasm Components don't really distinguish between libraries and applications;
Components are always sets of function imports and exports. Still though, there
are components which don't define their own typed interfaces and instead
directly map to common environments such as wasi:http or wasi:cli. These
components feel very much "binary-shaped" and tend to be easy to run.
- sample-wasi-http-rust (package): A sample
wasi:httpserver written in Rust. - sample-wasi-http-js: A sample
wasi:httpserver written in JavaScript. - sample-wasi-http-kotlin: A sample
wasi:httpserver written in Kotlin.
Libraries
Wasm Components provide fully typed interfaces, which can be linked to from any language using Bindings Generators. This makes Wasm Components a particularly portable way to package up libraries. Libraries can also be layered and implemented in terms of one another. This makes it possible to bring a large amount of complex functionality out of the runtime, and into components.
- fetch-rs (package): Fetch content from a URL.
- eval-py (package): Dynamically evaluate a Python expression.
- filesystem-rs (package): Access the filesystem.
- get-weather-js (package): Get the weather for a specific location.
- gomodule-go (package): Look up Go module information by name.
- timeserver-js (package): Get the current time.
- qr-code-webassembly: Generate a QR code from a URL.
Interfaces
Interfaces in Wasm are defined using WebAssembly Interface Types, or WIT for short. There are the standard WASI-based interfaces which are developed as part of the Wasm SG in the W3C. But anyone can define their own .wit interfaces and package them up.
- wasi:io (package): Standard interfaces for I/O stream abstractions.
- wasi:clocks (package): Standard interfaces for reading the current time and measuring elapsed time.
- wasi:random (package): Standard interfaces for obtaining pseudo-random data.
- wasi:filesystem (package): Standard interfacing for interacting with filesystems.
- wasi:sockets (package): Standard interfaces for TCP, UDP, and domain name lookup.
- wasi:cli (package): Standard interfaces for Command-Line environments.
- wasi:i2c: Standard interfaces for reading and writing data on embedded devices over an I²C connection.
- wasmcp:mcp (package): A WIT representation of the MCP specification.
- zed:extension: The extension interface for the Zed editor. Includes support for interacting with LSP and DAP.
- browser.wit: An automatic translation of the browser's Web APIs into WIT.
- grafbase:sdk: Extensions to the Grafbase GraphQL Gateway.
Tip
To convert a directory of .wit files to a .wasm file to publish it on a registry you can use wkg:
$ wkg wit build -d wit/ -o my-interface.wasm
To get the interfaces from a .wasm and store it as a .wit you can use wasm-tools:
$ wasm-tools component wit my-interface.wasm -o my-interface.wit
Resources
Tutorials
- Building Native Plugin Systems with WebAssembly Components by Sy Brand
- WASM Component Model in Raw WASM by Gert van Valkenhoef
License
Apache-2.0 with LLVM Exception