It's a JavaScript API, it only runs in the browser. It's not real.
I'm literally writing native code running on linux with winit and wgpu right now.
But WebGPU in the browser is also an adapting layer between those technologies, it's just the browser that does the adapting instead of the wgpu library. For Firefox, WebGPU is adapted to those underlying systems by wgpu: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
† There are some "native-only" extensions beyond the WebGPU spec that gpu provides, so it does go a little beyond WebGPU. But for the most part, it's very similar.
That and portability. The ergonomics are always up for debate, but I find it a much more modern and nicer interface than OpenGL which feels...quite dated. How it compares to something like Vulkan or Metal is up for debate.
But for portability if I write my code using directx, then I can only run it on systems with directx. If I write it for vulkan, I can only target systems with vulkan. If I write for metal, I can only target systems with metal.
However, if I use wgpu and the WebGPU API, I can target any system that has directx or vulkan or metal or OpenGL. I can also target wasm and compile my application for the web.
So, I can really easily write code that will run natively on linux, on osx, on windows and the web and will use the graphics library native to that platform.
wgpu is also not a graphics API, it's a library that abstracts the underlying graphics API.
(edit: thanks for editing your post. the revised version clears it up!)
wgpu is a regular library that uses the native APIs above and abstracts them from you. I don't like calling it a graphics API because it implies it's the same as the vendor-provided APIs - it's a completely different beast.
WebGPU and WebGL are Web standards that the browser implements, and you program them via JS. Similarly to wgpu, they're implemented on top of the native graphics APIs.
The relationship between wgpu and WebGPU is that they're basically made by the same people, and in Firefox WebGPU is implemented on top of wgpu.
But saying "WebGPU runs everywhere" is plain wrong - it's a browser-exclusive API, and on top of that, at the point of writing this it doesn't even run on all browsers (71% support according to https://caniuse.com/webgpu)
I think that’s understating the relationship a bit. The wgpu API follows the WebGPU spec quite closely. It’s like saying “taffy isn’t flexbox”. You can make a technical argument that it’s not identical, and to be flexbox it must be in a browser, but anyone working with taffy will recognize that it’s implementing flexbox and will find that all their understands of flexbox apply to taffy.
Similarly, most of what I’m learning working with wgpu (outside of, maybe, threading), is directly transferable to WebGPU. And vice versa.
But the "knowledge is transferable to WebGPU" is key. Even when you're compiling your wgpu code to WASM, you're not using WebGPU directly - for every API call, you're going through generated bindings on the Rust side and then generated bindings on the JS side where the actual call is made. The JS wrappers aren't trivial either - Rust structs need to be converted to the nested JS objects required by WebGPU spec, numeric enums need to be converted strings, etc.
Considering that WebGPU is supposed to be the low-level graphics API for the Web, DX12/VK/Metal equivalent, all this is at least worth a mention, and "wgpu == WebGPU" brushes over a all that, to the point where we're now casually throwing statements like "[WebGPU] is guaranteed to run anywhere, including the browser".