WebGPU
The modern low-level graphics-and-compute API for the browser — the successor to WebGL. Exposes contemporary GPU features (compute shaders, explicit memory management, bindless resources) to JavaScript/WebAssembly, with its own shading language WGSL (Rust-like, vs WebGL’s GLSL). By 2026 it sits around ~82–87% global support (Chrome/Edge/Opera/Samsung since v113, Safari 26.0+; Firefox the notable holdout). The rendering-backend node the spoke’s web engines reference but never paged.
Why it matters to the spoke — the rendering-backend dimension
Every web-graphics tool here names its backend, so WebGPU vs WebGL is a real axis that separates modern from legacy web rendering: Three.js, PixiJS, Babylon.js, and PlayCanvas all render on WebGL and WebGPU, with WebGPU the path to console-quality performance in the browser. So the web-graphics matrix has, beneath its library/engine split, a shared backend layer: the engines compete partly on how well they exploit WebGPU.
Cross-spoke seam (a bridge out of the island)
WebGPU is not only graphics — its compute shaders make it a general-purpose in-browser GPU compute API, used for client-side AI inference (running models in the browser). That is a live seam to llm-inference-wiki (browser-side model serving) and a rare concrete bridge between game-engines and the LLM stack: the same API the web engines render with also runs neural nets client-side. A candidate cross-spoke thread if browser-inference sources arrive.
Related
three-js · pixijs · babylonjs · playcanvas · synthesis