Tools: Why WebGPU Feels Like the Future of the Web (Live Demo 🚀)

First things first: why GPUs? ## So… how is this different from WebGL? ## Is WebGPU production-ready? ## WGSL – those “weird” new shader files ## Now, about my demo ## React… for a WebGPU demo? ## A TypeScript gotcha ## Final thoughts 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. 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: 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. WebGL is based on OpenGL, which is… well… old. Very old in GPU years. 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: In short: WebGPU is how GPUs actually work today. The honest answer: it depends. → then yes, WebGPU is absolutely usable today. → 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. WebGPU introduces WGSL (WebGPU Shading Language). At first glance, it looks strange — but if you’ve ever seen shaders for: …it actually feels quite familiar. 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. 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: 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. 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: 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. 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. Repository: https://github.com/sylwia-lask/webgpu-neon-demo Live demo: https://sylwia-lask.github.io/webgpu-neon-demo/ 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 🚀 Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - graphics and image processing - simulations - matrix-heavy workloads - and yes — things like LLMs - 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 - explicit compute passes - explicit pipelines and bind groups - no magical global state - APIs that map directly to modern GPU architectures (Metal, Vulkan, DirectX 12) - require modern browsers - target up-to-date Chrome, Edge, Firefox, Safari - you have a very broad audience - someone out there is still using an ancient Safari - or (please no) IE 11 - or modern DirectX - strongly typed - designed to avoid a whole class of GPU bugs - 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 - easy state management for sliders - zero manual DOM wiring - Repository: https://github.com/sylwia-lask/webgpu-neon-demo - Live demo: https://sylwia-lask.github.io/webgpu-neon-demo/