WebGPU is the hot topic right now. A brand-new web API that will most likely replace WebGL sooner rather than later (I won't miss you, bro đ).
Itâs already supported by all major browsers, and honestly⌠how could I not try it?
So I did what any curious frontend-centric software dev would do: I built a small interactive demo and learned a lot more than I initially expected.
First things first: why GPUs?
For many of you this might sound obvious, but letâs do a quick intro for anyone new to this area.
CPUs are great at doing a few complex things one after another.
GPUs are great at doing simple things, massively in parallel.
Thatâs why GPUs shine in:
- graphics and image processing
- simulations
- matrix-heavy workloads
- and yes â things like LLMs
Whether youâre rendering pixels, blurring textures, or multiplying huge matrices, GPUs are simply built for this kind of work. WebGPU finally gives us proper access to that power directly in the browser.
So⌠how is this different from WebGL?
WebGL is based on OpenGL, which is⌠well⌠old. Very old in GPU years.
With WebGL:
- there were no real compute shaders
- everything had to be expressed as a ârendering problemâ
- lots of hacks, tricks, and workarounds
- a lot of hidden global state
If you ever implemented GPGPU in WebGL, you probably remember encoding data in textures and pretending triangles were something else entirely đ
WebGPU fixes this properly:
- explicit compute passes
- explicit pipelines and bind groups
- no magical global state
- APIs that map directly to modern GPU architectures (Metal, Vulkan, DirectX 12)
In short: WebGPU is how GPUs actually work today.
Is WebGPU production-ready?
The honest answer: it depends.
If you can:
- require modern browsers
- target up-to-date Chrome, Edge, Firefox, Safari
â then yes, WebGPU is absolutely usable today.
If, however:
- you have a very broad audience
- someone out there is still using an ancient Safari
- or (please no) IE 11
â then you either invest in a WebGL fallback, or you skip WebGPU for now.
For experiments, demos, internal tools, and forward-looking products?
Itâs already a very solid choice.
WGSL â those âweirdâ new shader files
WebGPU introduces WGSL (WebGPU Shading Language).
At first glance, it looks strange â but if youâve ever seen shaders for:
- Metal
- Vulkan
- or modern DirectX
âŚit actually feels quite familiar.
WGSL is:
- strongly typed
- explicit
- designed to avoid a whole class of GPU bugs
In this project I keep shaders in separate .wgsl files, but you can also inline them as strings in TypeScript if you want. VS Code already has syntax highlighting for WGSL in both cases, which helps a lot.
Now, about my demo
I wonât lie â this demo was harder to write than many of my other experiments.
Maybe itâs because WebGPU is still relatively fresh.
Or maybe itâs because Iâve never been particularly passionate about computer graphics⌠and this demo is very graphics-heavy.
But in the end? Iâm really happy with the result.
Visually, it looks like glowing ink or smoke that appears when you move your cursor across the canvas.
Technically, itâs a GPU-driven simulation where:
- pointer input injects color into a floating-point texture
- compute shaders blur and transport that data over time
- values slowly fade out, creating trails
- a render pass displays the result
Is it physically accurate? Absolutely not đ
Does it look cool? Oh yes.
Live parameters like trail length, brush size, swirl strength, and color can all be tweaked via a control panel â no shader recompilation needed.
React⌠for a WebGPU demo?
Most WebGPU demos youâll find are written in plain HTML + JS. I couldâve done that too.
But I decided to use React + TypeScript as a thin wrapper:
- clean UI
- easy state management for sliders
- zero manual DOM wiring
It worked great â with one important caveat.
To make this demo usable, I had to disable React Strict Mode.
Why? Because Strict Mode intentionally runs effects twice in development to detect side effects. Thatâs normally fantastic⌠but not when youâre creating GPU devices, pipelines, textures, and buffers. Double initialization can break things very quickly.
Low-level GPU code is one of those rare cases where Strict Mode gets in the way.
A TypeScript gotcha
One more small thing:
TypeScript doesnât ship WebGPU types fully enabled out of the box yet.
You need to explicitly enable WebGPU typings in your TS config, otherwise none of the GPU types will exist. Itâs a one-time setup, but worth mentioning if youâre trying this for the first time.
Links
Repository:
https://github.com/sylwia-lask/webgpu-neon-demo
Final thoughts
WebGPU feels like a real step forward for the web.
Not just âslightly better graphicsâ, but an entirely new class of things we can realistically build in the browser.
This demo is just a visual experiment â but it already shows how powerful, expressive, and fun GPU-driven web apps can be.
If youâve been curious about WebGPU⌠this is your sign to try it đ
Top comments (3)
Fantastic! Iâd been waiting for this article, and it was absolutely worth it. I finally understand the value of WebGPU (even if, for my personal use cases, itâs still fairly limited). I played with the demo â itâs brilliant. Tweaking the settings and seeing everything update live is genuinely enjoyable.
Thank you so much, Pascal! Iâm really glad the article and the demo helped clarify the value of WebGPU đ
And yes â I totally agree. In day-to-day dev work the use cases can feel pretty limited⌠until they suddenly arenât. Iâve had more than a few moments where a âsimpleâ feature turned into something that really needed serious performance, and then having tools like this starts to matter a lot đ
Absolutely â same here. And to be honest, given the kind of projects Iâm working on, I donât expect to need WebGPU anytime soon. But I was curious to see what it felt like in practice: the possibilities, the rendering, the kind of problems it can unlock down the road.
And your demo was perfect for that â it gave me a clear sense of where this tech could matter later, even if today my use cases stay pretty modest. Still, itâs great to see whatâs coming. đ