> Also, if you compare the sample code in the post with a sample of Vulkan code, I think it will be clear that a literal "WebVulkan" is a road best not traveled.
Are you sure? Don't forget about WebAssembly… Just as Emscripten currently exposes the original OpenGL ES API as a wrapper for WebGL, for the sake of porting existing C/C++ code that uses it, in the future there will be a desire to port Vulkan renderers to the web. That will be easier if the browser API is based on Vulkan; otherwise you'll end up with a shim on top of a shim. Also, the same arguments about developer familiarity that led to WebGL being designed as it is could apply just as well to Vulkan - albeit somewhat more speculatively, given Vulkan's newness.
It's likely there will be a need for a C++-level meta-API that can work on top of Vulkan, D3D and Metal. There's already been discussion of making such a thing. It would be nice if that could be exposed to WebAssembly via Emscripten.
But to what degree might this 'meta-API' be different than WebGPU/JS? Might this effort effectively end up creating two, new APIs, each with different vocabularies (one for JS, another for C or C++)?
The whole point of Vulkan/Metal/DX12 is that since GPUs have their own MMUs it's totally OK to seg fault your own process from the GPU side. You just crash your process, but you don't take down the system.
That line of thinking doesn't really translate well to a JS API.
Are you sure? Don't forget about WebAssembly… Just as Emscripten currently exposes the original OpenGL ES API as a wrapper for WebGL, for the sake of porting existing C/C++ code that uses it, in the future there will be a desire to port Vulkan renderers to the web. That will be easier if the browser API is based on Vulkan; otherwise you'll end up with a shim on top of a shim. Also, the same arguments about developer familiarity that led to WebGL being designed as it is could apply just as well to Vulkan - albeit somewhat more speculatively, given Vulkan's newness.