Quick summary
- React, canvas, OffscreenCanvas, and WebGPU are not mutually exclusive choices. They serve interface regions with different update cadences, interaction needs, and rendering costs.
- A rate-of-change decision framework avoids both extremes: putting everything in the DOM or moving everything to the GPU without a product reason.
- Map UI regions by update cadence, semantic requirements, and frame cost; select one continuous region for a renderer-isolation trial.
What happened
The movement from high-frequency React data to Three.js and WebGPU experiments points to one shared decision: choose rendering architecture by workload characteristics, not by technology labels. Ring buffers and OffscreenCanvas in React address one kind of load; Three.js with WebGPU work illustrates another.
Both suggest that a modern interface can contain several rendering domains, each with a different cadence.
Classify UI by its rate of change
The first domain is discrete UI: forms, menus, text, filters, and results that change through intentional actions. This area often benefits from the DOM and a UI framework because semantics, maintainability, and accessibility are central.
The second is continuous UI: streaming charts, dense timelines, particles, audio-reactive visuals, or 3D scenes. Here, per-frame work and the data path can matter more than the component model.
There is no universal threshold for canvas or GPU
Element count is not the only criterion. The same number of points may be fine when changed by a deliberate action, yet become a problem when they update continuously, resize, animate, and compete with input.
The decision should therefore follow a profile of the real experience: how data arrives, how people interact, what needs semantic HTML, and what needs continual redraw.
A practical three-layer model
| Layer | Responsibility | Example |
|---|---|---|
| Coordinating UI | Intent, discrete state, accessibility | React and DOM |
| Hot data | Windowing, aggregation, update cadence | Ring buffer |
| Renderer | Turning data into pixels | Canvas, OffscreenCanvas, Three.js/WebGPU |
This is not a mandatory architecture. It is a boundary-setting tool, so continuous work does not impose its cadence on the entire application.
A decision sequence for teams
- Start with the DOM and measure the real experience.
- Reduce displayed data through aggregation or windowing where appropriate.
- Isolate the continuous rendering region before changing the whole stack.
- Bring in WebGPU or 3D only when visual or interaction value is clear.
In 5 Minutes
- Choose a renderer by rate of change and user requirements.
- The DOM remains strong for semantic, discretely updated UI.
- Canvas or GPU fits continuously redrawn domains.
- Measure first, isolate hot spots, then add complexity.
Sources
- Sixty Frames for the Record: A Three.js Game, Seven Fly-Throughs, and a Wall of CRTs
- Run Rob Run: Building a Music-Reactive Goo with Three.js and WebGPU
- Relighting Images with Depth Maps and Three.js
- Creating an Interactive 3D Cluster with Three.js, TSL and Three Start
- Exploring Procedural Geometry with Three.js and WebGPU
- Garden Anomaly: A Tiny WebGPU and TSL Experiment
- High-Frequency Real-Time Data in React: From Ring Buffers to OffscreenCanvas
Why developers should care
A rate-of-change decision framework avoids both extremes: putting everything in the DOM or moving everything to the GPU without a product reason.
Recommended action
- 1Map UI regions by update cadence, semantic requirements, and frame cost; select one continuous region for a renderer-isolation trial.
