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

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 🚀