We just finished putting a handful of WebGL shaders behind the headings on this very site — the slow-rotating space hero, the paper-fold layers, the kinetic boxes. They are decorative, but building them put a question back in front of us that we had been quietly working around for a long time: why do our actual data visualizations feel so much more constrained than a throwaway background animation?
A shader running on the GPU will happily push a few hundred thousand animated elements at 60 frames per second on a laptop. Meanwhile the charts node in ET1 — our visual ETL product — starts to sweat well before that, for the same reason most charting tools do: it is drawing into the DOM, on the CPU, one element at a time. So we have started exploring a WebGL rendering path for visualization in ET1, and the early results are honestly a little freeing.
The wall we keep hitting
ET1 builds pipelines on a canvas — drag a node, transform, join, filter, output — and the Visualize category turns a pipeline’s result into charts: pie, donut, polar, bar. Like almost everyone, we built that on the open-source charting stack: the D3 / SVG / Canvas2D lineage that the whole industry reaches for. It is excellent software, and we are not knocking it. But it carries a ceiling that has nothing to do with how good the library is.
The ceiling is the rendering model:
- SVG-based charts create one DOM node per mark. A scatter plot of 50,000 points is 50,000 nodes the browser has to lay out, style, and hit-test. Long before that, pan and zoom go from smooth to slideshow.
- Canvas2D-based charts dodge the DOM-node explosion but still draw on the CPU, immediate-mode, one shape per call. Redraw the whole frame on every hover or brush over a large series and you are back to dropped frames.
- The chart taxonomy is the library’s, not yours. You get the chart types the library ships. Anything genuinely new — a custom density field, a GPU-blended overlay, a bespoke encoding — means fighting the abstraction instead of using it.
None of that matters for a 200-row bar chart. It matters a lot when the point of a tool is to look at the output of a real pipeline, which is frequently hundreds of thousands or millions of rows. The thing you most want to visualize is exactly the thing the open-source stack is least comfortable drawing.
Why WebGL feels less burdened
Moving the rendering to WebGL changes the math. Instead of one DOM node or one draw call per mark, you hand the GPU a buffer of all your points at once and it rasterizes them in parallel. The practical differences we are seeing in prototypes:
- Scale stops being the headline constraint. Hundreds of thousands of points render in a single draw call. The dataset size that used to decide whether a chart was even viable mostly drops out of the conversation.
- Interaction stays smooth. Pan, zoom, brush, and hover over a large series stay at frame rate because re-rendering is what the GPU is built to do cheaply. The interactivity that felt expensive becomes the default.
- The visual language is ours again. A fragment shader is a blank page. Density heatmaps, additive-blended overlays, smooth animated transitions between pipeline states, encodings that don’t exist as a named “chart type” — these become things you write, not things you wait for a library to support.
- One pipeline, one GPU buffer. ET1 already has the data in a structured, columnar shape at the end of a run. Streaming that straight into a vertex buffer is a much shorter trip than building a DOM tree out of it.
That last point is why this fits ET1 specifically rather than being a generic “WebGL is fast” observation. The product already produces clean, typed, sizable result sets. The visualization layer should be able to look at all of that, not a sampled-down, DOM-friendly slice of it.
What we are not claiming
This is exploration, not a shipped feature, and WebGL is not a free lunch. The honest trade-offs:
- Text, axes, and legends are still easier in SVG/HTML. Crisp labels, accessible tooltips, and tidy small-multiples are areas where the old stack is genuinely better, and the likely answer is a hybrid: GPU for the dense data layer, DOM for the chrome around it.
- Accessibility takes real work. A
<canvas>is opaque to a screen reader by default. Anything we ship has to carry an accessible data representation alongside the pixels — that is non-negotiable, and it is more effort than SVG, where the marks are already in the document. - We are not ripping out the existing charts. Pie, donut, polar, and bar on the current stack are the right tool for the common, small-data case. The WebGL path is additive — it is for the cases where the existing stack hits the wall, not a wholesale replacement.
So this is not “we rewrote ET1’s charts.” It is “we found a ceiling, and there is a well-understood way through it, and we are prototyping it deliberately.”
What’s next
We are prototyping the GPU rendering path against real pipeline outputs — large scatter and point-cloud views, density and heatmap encodings, and time-series with far more samples than an SVG chart would tolerate — and figuring out where the hybrid line sits between the GPU data layer and the DOM chrome. As it firms up, we will write about the specific encodings and the rough edges, the same way we did when we put the shaders on this site.
If you are running ETL and routinely staring at outputs your charting tool can’t comfortably draw, that is exactly the problem we are chasing. Take a look at ET1, or start a project and tell us what you are trying to see.