GoKawiilThe Future of wasi-gfx and wasi:webgpu June 7, 2026
by Sean Isom, Mendy Berger
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.
... continue reading