Over the past few years, we’ve been working to bring graphics to WebAssembly through wasi:webgpu, wasi:surface, wasi:frame-buffer, and wasi:graphics-context.
Through this process, it has become clear that the long-term stability goals of the core WASI subgroup and our needs for rapid iteration on UI interfaces are incompatible. WASI aims for decade-long architectural stability. In contrast, interfaces like wasi:surface still require significant evolution.
As the Wasm Component Model matures, we see a healthy shift toward projects building distinct ecosystems outside the official WASI namespace — such as the cloud-native wasmcloud:secrets, wasmcloud:messaging and wasmcloud:postgres interfaces developed by CNCF wasmCloud. Think of WASI as an operating system's standard library (handling low-level basics like time and filesystem), while specialized domains like graphics and database drivers belong in user-space libraries.
With WebGPU reaching stability as a W3C Candidate Recommendation, wasi:webgpu should continue to live in the wasi namespace as a low-level industry standard. The rest of wasi-gfx will be lifted out to its own namespace and governance to be built on top of this foundation as a complementary set of higher-level proposals that will continue to evolve.
Here is how we are splitting the path forward to give both ecosystems room to thrive.
The Plan for wasi:webgpu
Because wasi:webgpu is fundamentally mapped to the WebGPU web standard, its foundation is inherently stable. It will remain an official WASI specification.
- Async Support: We are actively moving the specification to P3 to leverage native Wasm async capabilities.
- Compliance: Work is underway to ensure we pass the official WebGPU Conformance Test Suite (CTS). We expect to share updates on this soon.
For context on this architectural split, you can read through the wasi-gfx GitHub discussion, where the push to separate core WebGPU from windowing surfaces began.
Deprecating wasi:graphics-context
Previously, wasi:graphics-context served as the connection point between WebGPU, frame-buffers, and surfaces. However, we have found a much cleaner design outlined in GitHub Issue #55. We are officially deprecating wasi:graphics-context since we can now achieve the same goals without it.
The Birth of the wasi-gfx Namespace
What happens to wasi:surface and wasi:frame-buffer? They aren't going anywhere — they are just getting a new home.
We are moving these interfaces out of the core WASI standard and into their own dedicated namespace: wasi-gfx (i.e., wasi-gfx:surface, wasi-gfx:frame-buffer). We chose this name to reflect our absolute commitment to building on top of the Wasm Component Model and the broader WebAssembly ecosystem.
This transition gives us incredible advantages:
- Faster Iteration: We can version interfaces like a nimble library rather than a rigid standard.
- Future Flexibility: This ecosystem structure will enable experimentation with other UI application interfaces, like audio or camera.
Continued Tooling Support
Our implementation tooling — including wasi-gfx-runtime and wasi-gfx-shim — will continue to fully support wasi:webgpu and the new wasi-gfx namespace side by side. Expect work on this to start landing over the next few weeks.
A New Logo
We're excited to unveil a brand-new logo for wasi-gfx! As we establish our own namespace and identity, it felt like the right time for a fresh visual mark to represent the project.
Thanks to Abe Massry for designing and illustrating the logo — we love how it turned out!
A Place to Gather
Recently, the Renderlet Discord server has organically become the de facto meeting place for a couple of passionate engineers working on this effort. We’re making it official: the Renderlet Discord is now the official wasi-gfx server. If you want to chat about Wasm graphics or help contribute, come join us!