Three.js’s push toward WebGPU, TSL’s single-codebase shader authoring, and p5.js’s experimental WebGPU renderer have all been covered here this year as the visible, library-level side of the WebGPU transition. Underneath all of it sits a quieter number worth naming directly: WebGPU now reaches roughly 82% global browser support, and the browser vendors themselves are still shipping meaningful low-level improvements on top of that baseline.
Watch: What Is WebGPU? (YouTube)
What actually shipped at the browser level
Chrome 149 and 150 add WebGPU “immediates” alongside tightened transient attachment validation — changes aimed specifically at workloads that push many small, frequent per-draw updates rather than a handful of large ones. That’s a deliberately unglamorous kind of improvement: it doesn’t unlock a new visual capability the way compute shaders or the WebGPU renderer swap did, it just makes an already-possible pattern meaningfully cheaper to run, which matters most for exactly the kind of generative and particle-heavy work covered in the Three.js compute-shader coverage here previously.
Why the adoption number matters as much as any single feature
A rendering API is only as useful as the share of visitors who can actually run it, and 82% global support is the point where “WebGPU with a WebGL fallback” stops being a hedge against a niche audience and starts being closer to “the default path, with a shrinking safety net.” That crossing point is why library authors have felt comfortable shipping WebGPU-first renderers with automatic fallback rather than treating WebGPU as an experimental opt-in most users will never see.
Why the small stuff is the actual story here
Compute shaders and million-instance particle systems get the demo reels; validation tightening and per-draw update handling get a changelog entry nobody screenshots. But generative art, livecoding visuals, and real-time audio-reactive work — the actual daily-use case for a lot of the creative coding covered on this site — depend more on consistent frame timing under many small updates than on any single headline capability. Chrome doing the boring optimization work here is arguably a bigger practical unlock for that kind of project than the renderer swap itself, precisely because it’s invisible until the frame rate stops dropping.