Targeting all three can be tough, hence WebGPU which lets you write to a single API. Support on non-web runtimes have been appearing as well, so you're not necessarily limited to the browser (e.g. https://github.com/samdauwe/webgpu-native-examples).
Good read: https://surma.dev/things/webgpu/
Tutorial for learning Vulkan: https://www.vulkan.org/learn#vulkan-tutorials
I really do not recommend DX11 / DX12 / Vulkan / WebGPU, just because of the fact that they don't have that much good learning resources compared to OpenGL. Even DX (though more widely used in the gaming industry) doesn't have that much material compared to OpenGL. People often point at RasterTek's tutorials (https://www.rastertek.com/tutindex.html) for DX stuff, but the explanations are much more sparse compared to LearnOpenGL and they often just dump lines of code at you without any high-level explanation. And I especially do not recommend Vulkan (or DX12), because it's a hell of an unfriendly API that exposes too much of the underlying GPU hardware for the programmer to manage (especially with synchronization). Writing Vulkan in a naive way will probably give you less performance than what you will achieve with naive OpenGL / DX11. And using Vulkan in an optimal way isn't something that's explained in any Vulkan book or tutorial you can find online/offline: they generally teach how to do simple stuff (like drawing a triangle, which is essentially what learnvulkan.com does), but do not really teach you with the more important architectural decisions when writing a performant renderer (this I am currently struggling, and searching through blogs/papers/videos as much as possible).
WebGL 2 on other hand works today and is about the only way to do portable 3d (unless you use higher level engines). .
[1] apparently a preview appeared in Safari tech preview releases in 2019 when Apple was trying to argue for more Metal style API design in WebGPU, but since disappeared from there. https://developer.apple.com/forums/thread/692979
also, for a cross-platform tool i expected that clicking the images would take me to live demos that work in a browser, not mp4 and png files.
Our browser support is still a work in progress (and browsers don't support WebGPU yet), so we primarily run on windows/linux/macOS natively right now. Once that improves we will replace them with actual browser demos.
I think this means the future of graphics APIs is software abstractions around the truly native APIs (DirectX, Metal, etc.) - things like WebGPU, sokol_gfx, SDL's new GPU abstraction, and Sebastian Aaltonen's stuff.
On the Switch if your really want the full 3D capabilities, NVN is the answer.
(D3D11 is not a typo, unfortunately D3D12 isn't that much better than Vulkan in that regard)
All of them use the platform's API to take advantage of all features, while providing a more high level of 3D programming concepts.
And which doesn't exist (except behind a flag, will probably ship in Chrome 113). And the spec already has over 1500 issues (over 300 still open).
So... It's not "targeting three graphics APIs is tough, target just WebGPU". It's "here's a third incompatible graphics API for the web (after Canvas and WebGL), and people may expect you to also support it an addition to non-web APIs"
Why would I?
> There's already game engines & graphics libraries being made thru one of the WebGPU implementations, and you can always start using it now after some setup
Again, what's the point? Just to say "oh look I can"?