The WebGPU migration in creative-coding JavaScript has been going on long enough that “supports WebGPU” has stopped meaning much. Usually it means a renderer exists, some subset of features works, and the examples that ship are the ones that happen to run.
deck.gl v9.4, released September 5, 2026, is a more specific claim: all official layers, ported, at parity.
What “all layers” covers
The release notes the entire official catalogue now runs on WebGPU and achieves render parity with the WebGL version. The awkward ones are named explicitly:
- MVTLayer with tile clipping
- Tile3DLayer with point-cloud and glTF support
Those two matter because they’re where a partial port usually stops. Vector tile clipping and streamed 3D tiles involve enough per-layer GPU plumbing that “we ported the scatterplot layer” tells you nothing about whether they work.
The rest of 9.4
The WebGPU work sits alongside a batch of changes that are, for most people, more immediately useful:
- GlobeView gained pitch and bearing, and TerrainLayer now renders correctly on it
- Controller options:
doubleClickDragZoom,trackpadGesture,maxBoundsPadding, andrubberBandelastic navigation bounds @deck.gl/maplibre, a new module supporting MapLibre GL JS v4, v5 and v6- Antialiasing for PathLayer, LineLayer and ArcLayer
- PathStyleExtension adds
dashModeanddashUnits - FillStyleExtension generates procedural patterns with no texture atlas
- Picking performance optimised via shader builtins; TileLayer now prioritises viewport-centred requests
The elastic bounds and trackpad gesture support are the quiet wins. Navigation that fights the user is the most common way a good visualisation gets abandoned, and rubberBand is the fix for the specific misery of hitting a hard pan limit.
Read the warning
deck.gl’s own documentation, as of this release, says:
WebGPU support remains experimental and is not yet recommended for production.
and adds that “some layers and features remain unavailable or only partially supported.”
So hold both facts at once. Every layer has been ported and matches the WebGL output. The project still does not want you shipping it to users. Those aren’t contradictory — parity on the layers is a necessary step, not a sufficient one, and the remaining gaps are in the surrounding surface area rather than the layers themselves.
The practical reading for anyone building with this: WebGPU in deck.gl is now worth prototyping against, because you can build the thing you actually want to build rather than working around a half-ported catalogue. It is not yet worth betting a deadline on. When a project is this explicit about the distinction, it’s usually because someone has already been burned by the difference.