Main advantage of WebGPU is compute shader support, which allows to move more work from the CPU to the GPU with much less hassle than WebGL2, and it also moves most state management from the 'render phase' into the 'initialization phase' (at the cost that almost all state is baked into immutable objects, so you better know upfront all state combinations you're going to need later during rendering).

Don't expect an automatic jump in performance when naively porting well-optimized WebGL code to WebGPU though, currently WebGPU is still in the "make it work" phase, and not yet in the "make it fast" phase. Some high-frequency calls currently have much higher overhead in WebGPU than comparable calls in WebGL2. Case in point, this 'microbenchmark' demo is slower in WebGPU than WebGL2 (in Chrome at least, haven't tested elsewhere yet):

WebGPU version: https://floooh.github.io/sokol-webgpu/drawcallperf-sapp.html

WebGL2 version: https://floooh.github.io/sokol-html5/drawcallperf-sapp.html

Funnily enough, we've never actually been on WebGL! The runtime's built against wgpu [0], which is an abstraction layer that supports the native rendering APIs, WebGPU, and yes, WebGL.

However, our renderer was built with native capabilities in mind (compute shaders!), so we would have had to rewrite it to support WebGL. We decided we'd keep up with WebGPU and see where it takes us :)

In the future, we may write a fallback renderer that's compatible with WebGL/older GPUs, but we wanted to focus on getting our existing renderer working first.

[0]: https://github.com/gfx-rs/wgpu

Pros: It's basically just a more modern API, so we can do a lot more (compute shaders for instance). There's a lot we can do on the performance side with it to make it faster than what we could do with WebGL. Cons: It's not yet available on all browsers unfortunately.

The major con is that only 28% of internet users have a WebGPU-supported browser, mainly because it's not yet supported on any mobile devices.

https://caniuse.com/webgpu