The question I get most
Somewhere in the first week of learning shaders, everyone hits the same fork. Should I be learning WebGL or WebGPU? The internet is not helpful here. Half of it was written before WebGPU shipped anywhere, and the other half reads like a spec.
I've been writing shaders on the web for a long time in GLSL, and everything in Fragments for the last year has been WebGPU-first through Three.js and TSL. So this is how I think about it for creative coding. Generative art, interactive visuals, shader-driven UI. Not for shipping a game engine.
What actually changed
WebGL is a browser wrapper around OpenGL ES, an API designed in the 2000s around a fixed pipeline. Vertex shader, fragment shader, done. WebGPU is a wrapper around the modern native APIs, Vulkan, Metal, Direct3D 12, and it brings their model with it.
For creative work, three of those changes matter more than the rest.
Compute shaders. Shaders that run calculations instead of drawing pixels. Particle systems, physics, flocking, cellular automata, sorting. Anything that used to be "simulate on the CPU, upload every frame" or a ping-pong of textures now runs directly on the GPU with a normal-looking loop. The flow field and pixel sorting techniques in Fragments both rest entirely on this. In TSL it's a Fn with .compute(count) on the end; the Compute Stage section of the official guide covers workgroups and shared memory if you want to go further than that.
Storage buffers. Big, typed arrays that live on the GPU and can be read and written by shaders. In WebGL the workaround was to encode your data into a texture and decode it with careful UV math. In WebGPU you write positions.element(index). The Storage Buffers page shows the shapes I use most; the guide's Storage section has the full API.
A new shading language. WGSL instead of GLSL. Different syntax, same ideas. This is the one people worry about most, and it's the one that matters least.
There's also better multi-render-target support, cleaner state management and generally less driver weirdness, but those are quality-of-life rather than "now I can make a thing I couldn't make before."
What didn't change
A fragment shader is still a function that runs for every pixel. UV coordinates, sin(), fract(), mix(), smoothstep(), SDFs, noise, domain repetition. Every fundamental transfers untouched. The Shader Vocabulary doesn't have a WebGL column and a WebGPU column, because the concepts are the same.
If you know how to make a geometric pattern in GLSL, you know how to make it in WGSL after an afternoon. The learning that takes years is the visual thinking, not the API.
Browser support in 2026
This is where the advice flipped in the last year. Chrome and Edge have shipped WebGPU on desktop since 2023 and on Android since early 2024. Safari turned it on across macOS, iOS and iPadOS in September 2025. Firefox followed on Windows and Apple Silicon Macs over 2025. So every major browser now ships it by default on its main platforms.
The remaining gaps are the long tail: some Linux configurations, Firefox on Android, and anyone on an OS too old to update. For a portfolio piece or a landing page that's a small and shrinking slice. For an enterprise dashboard it might still be a blocker.
I'm deliberately not listing version numbers here, because they'll be stale within a quarter. The implementation status wiki is the source of truth; check it the week you ship.
The fallback question
With Three.js you don't really have to choose.
WebGPURenderer falls back to WebGL 2 when the browser has no WebGPU. If you write your shaders in TSL rather than raw WGSL, the same shader compiles to WGSL on WebGPU and to GLSL on the fallback path. The TSL guide calls this "future-proof portability", and it's why Three now describes TSL as its shader standard rather than an add-on. (You might see a sneaky testimonial from me on that page - I love using TSL and have been building with it since before it had a guide, and I'd make the same bet again.) Compute shaders are the exception. They have no WebGL equivalent beyond some interesting workarounds, so a piece built on them either needs a CPU fallback or a graceful "this needs a newer browser" state.
That's the model Fragments is built on. Every technique is written once in TSL. The fragment-shader-only ones run everywhere. The compute-heavy ones are WebGPU-only and say so.
Performance, honestly
The headline numbers you'll see, "10x faster!", are about compute workloads and draw-call-heavy scenes. For a full-screen fragment shader doing raymarching or noise, WebGPU and WebGL 2 are within spitting distance. You're bound by the same GPU running the same math.
Where it actually gets faster is anything that used to fight the CPU. A million particles, a fluid sim, a sort. The ethereal flow field pushes a million sprites through several post passes at 120fps on a laptop. That piece is not possible in WebGL without heroics.
So which should you learn?
If you're starting now, learn shader fundamentals in whatever gets you to a result fastest, and build in WebGPU via TSL.
- Use Shadertoy and the Book of Shaders for the fundamentals. They're GLSL, that's fine. The concepts are the point. I wrote about this path in how to learn shaders.
- Build your own projects in Three.js with
WebGPURendererand TSL. You get the fallback for free and the compute path when you want it. The TSL primer is where I'd start. The WebGPU Scene and boilerplate skip the setup. - You don't need to learn raw WGSL first. Learn it through TSL. You'll read the generated output when debugging and pick it up passively. The debugging TSL page shows how, and TSL's built-in
debug()node prints the generated WGSL or GLSL for any expression.
If you already know GLSL well, same answer. You'll be productive in a weekend. The functional, chained style of TSL is the only real adjustment, and you don't have to throw your old code away: glslFn from three/tsl drops a GLSL function straight into a TSL graph on the WebGL backend, and Three ships a transpiler that turns GLSL into TSL or WGSL, so a Shadertoy snippet can be ported mechanically rather than rewritten by hand.
If you must support Linux Firefox or older Android today, and your piece has no compute, write TSL, ship WebGPURenderer, and let the fallback do its job. You lose nothing.
The bit I'd stress
WebGL taught us to think in pixels. WebGPU doesn't replace that. It adds a second way of thinking, in buffers and parallel work, and that's where most of the new visual ideas are coming from. Flow fields, feedback systems, huge instanced scenes, real-time sorting. Learning it now isn't early. It's roughly on time.