The rigid resource binding model via BindGroup objects in WebGPU is already outdated (and funny enough, an area where WebGPU is actually slower than WebGL2, at least when assuming that bindings need to change frequently and unpredictably).

This was a restriction of the Vulkan 1.0 API and modelling the WebGPU resource binding model around that was a quite predictable problem. It would have been better to come up with a slim abstraction that might cost some performance on Vulkan (which is only really relevant on Android phones and Linux desktops), but at least would not slow down WebGPU across all platforms.

And now even the Vulkan maintainers have realized the problem and are introducing the much more flexible descriptor-heap extension (about a decade late, but better late than never).

WebGPU is essentially the frozen cross-section of 3D APIs from about a decade ago, and the state of GPU hardware from about 15 to 20 years ago (but tbf, apart from the broken binding model there wasn't much that could be done, because most restrictions are coming from mobile GPUs which a browser 3D API simply must support).

1. monolithic pipelines, pretty much no hardware works like that, the hash-and-cache design makes your design inflexible and adds a ton of overhead

2. WGSL, like come on

3. Hilariously outdated feature set, no mesh shaders, no HWRT, cooperative matrices/tensors, etc.

4. It's security-focused because web untrusted code:tm: so most of the calls are hilariously slow. Yes even the desktop implementations. There's no good webGPU implementation out there

5. it's also not simple to either implement or use. it's basically vulkan's difficulty without any of the advantages....