I've heard that learning WebGPU is a pretty decent alternative, it's cross-platform, has runners that are non-web, and has some of the niceties of Metal without being platform lock-in
Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.
"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.
You always need to explicitly say which platforms you target, and then test on those platforms.
The main questions should be "on which platform will my users run it" and "can I debug and test this".
So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).
Indeed, and a well regarded WebGPU guide is also trending on the front page at the same time :P
The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM. In that regard there are also some interesting projects/opportunities.
"The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM"
Having shipped non-trivial WASM code in two projects That's not a positive thing. WASM is stuck in zone between living and the dead - just good enough (barely) to merit creating production code when you need the perf in browser but not good enough to register as industrial quality tool as it's not possible really to debug a WASM application.
If you really, really need the perf in your browser app, WASM may be the only option, but it's not really a good one.
After 15 years, browsers vendors still don't care about 3D APIs on the developer tools, you need to have a native version and hope that the issue is actually on your code and not something that the browser does.
Because of its nature and the browser sandbox, you have no idea if the application is actually working on customer browsers, or even be able to have workarounds like on native APIs.
Finally it lags a decade behind hardware capabilities being surfaced on the API.
However there is nothing else on the browser.
The only positive thing is being 3D APIs designed with managed languages in mind.
Actually, at least on Chromium it's possible to use Dwarf debugging symbols in debugging your wasm files. It's a little tricky because the documentation isn't that clear but I've ran programs through that and it works. Also there a vscode extension (which I prefer over using vs the browser devtools). If you have that it's basically like using any other debugger in vscode (including CodeLLDB) only you launch the browser when you're debugging it.
The extension is "feature complete" and works. Why should it need updates when it's not broken?
It should also work for all compiler toolchains that generate DWARF debug info, which is pretty much standard across all compiled languages, otherwise gdb or lldb couldn't be used either with those languages (Microsoft of course does its own thing, as is tradition, but its not like msvc supports wasm output in the first place - Blazor oth appears to support wasm debugging in VS and VSCode)
Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.
"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.
You always need to explicitly say which platforms you target, and then test on those platforms.
The main questions should be "on which platform will my users run it" and "can I debug and test this".
So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).