The problem is that you don't get *any* error messages from native GL in the first place (unless you wire up a debug-message callback via the optional KHR_debug extension which isn't available everywhere), and the builtin error system via glGetError() is pretty much completely useless.

Other APIs don't suffer from this problem, D3D, Vulkan and Metal all have excellent validation layers which give very helpful messages, and WebGL or WebGPU running in browsers basically implement such a validation layer out of the box.

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).

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....