A massive shame that it's more or less bolted to the Sodom and Gomorrah of modern software development (Browsers and JS). Atleast in mindshare for sure.
There appears to be a non browser implementation of WebGPU now looking into it, but I can't find anyone using it or attempting to use it in production
https://github.com/webgpu-native/webgpu-headers/blob/main/we...
...and this standardized API would also enable other independent native implementations (and shader compilation aside, it's actually not in the realm of the impossible to write a WebGPU implementation from scratch with a small team or even alone).
There's even thought put into the API being extensible via 'struct chaining', this is how the native implementations also accept SPIRV shader bytecode instead of just WGSL shader source code.
If you're building an application, you'd better make sure you are using _the implementation's version_ of the webgpu.h header today.
Hopefully one day it does become fully standard.
Despite my usual rants on how they are outdated in regards to native APIs, there is a great plus for them, WebGL and WebGPU are the only 3D APIs designed from scratch for managed languages.
It goes beyond it, because CPU-GPU interfaces were also designed with JavaScript GC in mind.
Hence why on Android they are finally thinking about using WebPGU to expose Vulkan to app developers, as most keep using GL ES instead of downgrading their developer experience dealing with NDK, C and C++.