There are three levels of shims between the user application and the GPU - WGPU, the Vulkan library, and the Vulkan driver for the GPU. This varies a bit with the platform. None of these do much work. They mostly move data around.
To draw something, with modern basic 3D graphics, the application creates a mesh object, which is a few big arrays. There are vertices with X, Y and Z coordinates, triplets of vertex indices to define triangles, and some other info. You create texture objects, which are just 2D pictures in memory. Each object has a transform, a 4x4 matrix that transforms it into world space, and finally there's a camera transform which projects the scene onto the flat screen. And you provide some shader programs which run on the GPU to process that data.
All that data is moved, usually unmodified, into the GPU. Or placed where the GPU can reach it, in systems with "integrated graphics". The GPU's hardware and firmware then take that data and draw it.
So what are WGPU and the Vulkan layers doing? Managing memory, time and safety. They're responsible for allocating GPU memory, interlocking against changing data in the GPU while the GPU is doing something with it, and preventing cross-process memory accesses by keeping the GPU from doing things to memory of another process. This is more like the job of an operating system than a graphics program. These levels of the graphics stack don't do much graphics. The application says what to do in formats the GPU hardware understands.
There's a lot of cross platform stuff going on. WGPU can support quite a few graphics back ends. Its native language is Vulkan, but Direct-X is supported to keep Microsoft happy, Metal is supported to keep Apple happy, Android is supported to keep Google happy, WebGPU is supported to keep browsers happy, and OpenGL is supported to keep people with old hardware happy. There are some lowest common denominator problems; Android and WebGPU use subsets of Vulkan and run a few years behind desktop. The back end is not hidden from the application. Some special cases have to be handled, one of them being "integrated graphics". Also, Vulkan has a huge list of optional features, many of which are not available on older platforms. WGPU doesn't hide that; it tells the application what's available and the application has to handle it or say it can't.
It's all plumbing.
On consoles, you need few shim layers, because there's only one possible graphics device. The game code often goes directly to the hardware.
Although I feel like unless you need to specifically target web or extensive cross platform support, a better alternative for a higher level framework/library is nvrhi. Especially for C++ developers.
And I feel like if you are making for cross platform or web you are likely using Rust or writing your own game engine/library maybe I view of the ecosystem is skewed.
[dead]
But it's definitely not very mobile devices ready, you can get it to work though.
I feel like at the moment the kinds of things webgpu is good for unless it has to be a website it's better done with a native library.
Because otherwise webgl2 is much more broadly available for broadly supported platform set.
Pretty sure it's because GitHub allows the user to put content at the root of that URL. And it's an entirely separate domain to avoid cookie stealing or whatever.
People use github.io to host sites that are developed on github.com or around projects hosted on github.com.