https://webkit.org/demos/webgpu/scripts/hello-triangle.js
The advantages of WebGPU vs WebGL probably make sense to experts in this area, but I still find most of it to be completely impenetrable at first glance as a relative novice.
One of the expected advantages of WebGPU is exposing the inner workings of the hardware's GPU support in a more explicit manner. This leads to really verbose code. This is similar to API movements seen in DirectX, Vulkan, and Metal.
WebGL was never exactly easy to read either, but you could get started more easily. It tried being something in-betweenm though, and ended up never being the best at either providing explicit behavior, nor being friendly.
The idea of WebGPU going forward is that it will make it easier for other libraries to use it in a more deterministic fashion. If you know how the metal works, you'll be able to optimize the sh*t out of it. But for novices, you'll end up using some library or engine that abstracts away a lot of the hardcore functionality like "let's get an adapter that supports this specific texture extension" or "let's reuse a binding group layout to save 2ns when binding uniforms". In the same way most people on the web use Three.js (instead of WebGL), you'll see libraries like Babylon or Three.js making use of WebGPU without really having to know about all that stuff. And that's the right solution.
I've recently been playing with WebGPU and while it's still a bit of a boilerplate nightmare (which I wouldn't presume to know how to do better).. it was far more approachable.
Wrapping my head around buffers and layouts, and the fact that wgsl is a huge pain in the neck to debug, took a while.
I've built myself a really rudimentary perlin noise generator using compute shaders, and managed to pipe that into a rendering shader that uses two triangles to render part of the noise field onto a canvas really smoothly.
Trying to do some fancier compute stuff now, and overall the primitives are relatively straightforward. It's just that the documentation around the binding types and layouts, resource limits, and command-encoder/pipeline operational semantics are poor right now.
I admit this is a little bit more involved than calling glClear followed by glDrawTriangles, but once you reach the stage where you’re ready to apply textures and write shader code, the new way seems much more straightforward.
I still find most of it to be completely impenetrable at first glance as a relative novice
Think of it as going much lower level like doing your stuff in x86 assembly language, so, sure it's going to be a PITA to get something running but for that very special need where every bit of performance matters it's going to work well.