This isn’t a preview of the GPU web. It’s running.
Seventeen components, built on one shared WebGPU runtime, pre-1.0 and already drawing. Four of them are running together further down this page — one device, one frame, one submit — and every one of the seventeen has a live demo you can open.
npx @gpuc/cli add timelineThe component is copied into your repo, yours to edit; the runtime stays a versioned dependency on npm — @gpuc/core, @gpuc/react and @gpuc/cli, published early so the install surface can be argued with while changing it is cheap.
- GPUTimeline
- GPUHeatmap
- GPUDataGrid
- GPUScatter
- GPUGraph
- GPUImageDiff
- GPULogViewer
- GPUCandlestick
- GPUDensityMap
- GPUHistogram
- GPUDepGraph
- GPUNetworkTopology
- GPUAnnotationCanvas
- GPUSpreadsheet
- GPUNodeEditor
- GPUWhiteboard
- GPUPdfViewer
The DOM is out of headroom. The GPU is barely awake.
WebGPU reached Baseline in January 2026. The fastest chip in the machine is now a standard browser API, and it spends most of its life compositing rectangles while your interface drops frames next to it.
Baseline, not experimental.
Chrome and Edge since 113. Safari 26. Firefox 141 on Windows, 145 on macOS Tahoe ARM. Shipped, not proposed.
Under ten per cent left behind.
Linux Firefox, older iOS, locked-down enterprise browsers. They get the Canvas2D path at reduced capacity and are told so. Our estimate — we have not measured it ourselves.
Charts shipped. Runtimes didn’t.
One WebGPU chart is a weekend. A shared device under six different components is the part nobody built.
Everybody writes this UI three times.
First in DOM. Fine at a thousand rows, dead at five thousand — that is roughly the ceiling on primitives one JS frame can issue. So you rewrite it in Canvas2D and buy an order of magnitude: about fifty thousand fillRects at 60fps. Then the data grows again. Both ceilings are properties of drawing from a CPU loop, and no version of either platform raises them.
~5,000
DOM nodes one frame can touch
~50,000
Canvas2D fillRects at 60fps
1
draw call, for 250,000 scatter points
Nobody budgets for the third rewrite. Nobody has to do a fourth — above this one, the ceiling is the hardware.
Zoom is a uniform write, not a re-render.
A CPU pipeline re-walks the whole dataset on every pan, zoom, filter and brush. A GPU pipeline uploads it once. After that, interaction changes a few dozen bytes of uniform and the frame redraws from data that never moved — the dataset stopped being in the interaction path.
Per-element work runs on the hardware built for it
Colour mapping, normalisation, thresholding, LOD binning, min/max reduction — data-parallel work, run data-parallel.
Selection is a bitset the shader branches on
Brushing a hundred thousand spans does not mean touching a hundred thousand objects.
Compute lives in the data path, not beside it
Indirect dispatch and storage-buffer-driven vertex work are the durable WebGPU advantages. Fill rate is not.
Here are four of them. One device.
Six GPU panels on a page usually means six GPU devices, and that is the bug this project started from. Chart libraries exist; WebGPU charting already shipped. What does not exist is one runtime underneath components that are not alike — a timeline, a heatmap, a grid and a scatter plot on the same page, through one device, one frame loop, one submit.
Starting the runtime…
import { GPUProvider } from '@gpuc/react'
import { GPUTimeline } from '@/components/gpu/timeline'
// One init() → one Gpu → one GPUDevice, shared by every child.
<GPUProvider>
<GPUTimeline spans={spans} tracks={tracks} />
<GPUHeatmap data={matrix} />
</GPUProvider>- One command buffer per tick. Every mounted component’s passes land in a single
frame(), compute before render. - Shared caches. Pipelines, samplers, colormaps and transient uniforms exist once, not once per component.
- React never owns GPU state. Render state lives in refs and GPU buffers; React state is for semantics — selected ids, labels, the accessibility tree.
You own the component. We own the plumbing.
The runtime is infrastructure nobody wants to fork and everybody wants patched — device management, scheduling, leak fixes, device-loss handling. The component is policy: colours, LOD thresholds, label rules, interaction feel, shaders. That is exactly what teams need to change and what a props API can never anticipate.
npm i @gpuc/core @gpuc/reactVersioned, upgradeable, not yours to fork.
npx @gpuc/cli add timelineCopied into your repo, yours to edit.
No shader prop. No renderer prop. No uniforms prop. Extensibility comes from owning the source, not from an escape hatch.
Below the crossover, this library is slower than what you already have.
Upload cost and pipeline overhead dominate at small N. Every component ships a section titled “When NOT to use this”, with the measured crossover number and a recommendation for what to use instead. Canvas2D is better than most people assume: a canvas grid already scrolls millions of rows at 60fps today, and anyone selling you a GPU grid on scroll performance is selling you something you already have.
We publish the comparison whether or not it flatters us. Anything not yet measured on the harness carries a target label, on every page.
Seventeen components. All seventeen running live, right now, on your GPU.
- GPUTimelineSpans, flame graphs, Gantt and waterfalls. Up to 500,000 spans, pan, zoom, brush-select.
- GPUHeatmapA dense matrix with a GPU colormap and GPU auto-ranging, zoomable on both axes.
- GPUDataGridRead-only grid with per-cell conditional formatting evaluated in the fragment shader.
- GPUScatter250,000 points, one draw call. Zoom, filter and brush are all uniform writes.
- GPUGraphForce-directed layout running entirely on the GPU, settling in front of you.
- GPUImageDiffSplit, onion-skin, difference and heat comparison of two images, with a GPU pixel count.
- GPULogViewerHalf a million lines in a GPU ring, streaming appends, and match density over all of them.
- GPUCandlestick200,000 OHLC bars, revised tick by tick, with a whole-history envelope along the bottom.
- GPUDensityMap200,000 lon/lat points hexbinned on the GPU over Web Mercator — graticule chrome, no tiles.
- GPUHistogram250,000 values, Freedman–Diaconis bins at ingest, GPU atomic binning into instanced bars.
- GPUDepGraphSugiyama layered package DAG with orthogonal edges — layout once on the CPU, GPU draw only.
- GPUNetworkTopologyForce-laid service mesh with status, link health, and traffic pulse.
- GPUAnnotationCanvasA Float32 field with a GPU colormap and a host-owned rect/ellipse/point/ruler/polygon overlay.
- GPUSpreadsheetEditable cells, a dependency-graph formula engine, selection, clipboard, and pivot tables.
- GPUNodeEditorDrag nodes, drag-to-connect ports, multi-select and delete — all CPU-owned, GPU-drawn.
- GPUWhiteboardDraw shapes, select/marquee/move/delete — a procedural dot-grid canvas forked from GPUAnnotationCanvas.
- GPUPdfViewerA small resident-texture pool composites host-rasterized pages, virtualized and zoomable.
You’ve seen four of them run. There are seventeen.
The playground runs every component live, on your GPU, on your machine. Architecture, the scoring matrix, and the full “why not” live on their own pages when you want the detail.