Awesome Wasm Components

A curated list of WebAssembly Component tooling and ready-to-use components.

• Tools
  • Programming Language Support
  • Bindings Generators
  • Host Runtimes
  • Registries
• Components
  • Applications
  • Libraries
  • Interfaces
• Resources
  • Tutorials

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:

[!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.

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.

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:

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:

• AWS ECR
• Azure ACR
• Docker Hub
• GitHub Packages
• Google Cloud Artifact Registry

[!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:http server written in Rust.
• sample-wasi-http-js: A sample wasi:http server written in JavaScript.
• sample-wasi-http-kotlin: A sample wasi:http server 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