Sounds like you're focused on what is best for Vulkan, not what is best for the web.
That makes sense to me. What is special about the web that should exclude it from the single API narrative?
Remember claims of Flash being the necessary thing on the mobile web, and efficient too? It turned out it was never true.
Note there's still no web version of "pure" Vulkan. If it gets to be modified to be less "ridiculously low level" in its web variant, it is anyway going to come closer to the goal Apple proposes for the web.
Again, to quote from the Apples proposal: "We don’t expect this to become the actual API that ends up in the standard, and maybe not even the one that the Community Group decides to start with, but we think there is a lot of value in working code. Other browser engines have made their own similar prototypes. It will be exciting to collaborate with the community and come up with a great new technology for graphics."
---------------
Yes, it doesn't have a web API. That's because there's no existing web API for low-level graphics of this nature. The question is, what this API should look like. It seems natural to answer this question with, "whatever is the standard outside of the web". Now, there isn't one - but Vulkan is the closest that we have.
So, from an engineering perspective, if Apple does want standardization in this area, it would make sense to standardize on Vulkan for both web and non-web applications. Or if they want something else, like e.g. Metal, because Vulkan is somehow inadequate, then they should also submit Metal as a cross-platform standard API outside of the web.
Basically, this is trying to solve the standardization problem at a higher level in the stack, while ignoring the same exact problem one layer lower - despite the fact that there's a similar effort ongoing on that layer. Good design would dictate solving it at the lower level first, then building on that for the higher level.
I'm guessing the changes that may occur in the lower level aren't big enough to affect the upper level.
A lot of people in this discussion seem to just be operating under the assumption that the web API SHOULD be the same as the native API. But if you want a layer of indirection there for any reason (optimization, security, future proofing, whatever) then trying to be a one to one match to a lower level API may not be a good design decision.
There are one or two comments by the Apple people here on this point but not many from others: let's just assume the Vulcan is everywhere... would it still makes sense to use that (directly) as a web API? I'm not convinced it would.
Neverming the fact that it implied running a VM on a phone, tie themselves to Oracle in undesirable (read: licensing) ways, or that it was not the best technical choice: market forces (including dev skillsets in production, down to mass customer adoption) determine the winning strategies in tech. It's all about money, and waiting for hundreds of thousands of devs worldwide to train on a new tech isn't cheap nor easy nor fast.
So that's a good real-world example of a successful strategy that didn't make much sense from an engineering standpoint (surprising move by Google of all big tech, given their deep engineering DNA/culture).
However it's been stated time and again that most people Apple talked to regarding WebGPU are in agreement that this high-level web API should be able to target pretty much any and all low-level graphics API (DX12, Vulkan, Metal and perhaps others eventually, like NVN or other custom implementations on consoles etc.) So there's that. The reasons are probably as much political as they are technical (nobody probably wants to drop their own horse). It might require more work, and produce lesser results (in terms of performance) but ultimately that may be the way to make WebGPU succeed, regardless of who's proposing it.
If we look at the JS situation generally (ref: "what it's like using JS in 2016"), the same could be argued that standards are very much not the norm beyond W3C specs (because TypeScript this, framework that, Babel this, npm that, etc.) Is that a good thing? Some say yes. Is that a bad thing? Some say yes. If we end up having several disparate implementations of WebGPU we know it'll be the same: you have one problem to solve and a solution space that's 10x redundant -but what little idiosyncrasy you find in all this mess is also the reason why everyone and their mother can use JS (different problems meet a bunch of various solutions), it's also probably why the field is so dynamic.
The matter of the fact, imho, is that thinking of 3D on the web in 2017 without considering AR/VR from the get go is just a loss of time, and that implies catering to mobile (because the economic revolution of that will be shaped as portable glasses or lenses, not 60-pounds workstation). It's highly likely that these devices will rely on custom/new OS more of an IoT flavor, and in making these the classic vendors (MS, Google) can add whatever drivers WebGPU requires by then. In the meantime, it may be a reason not to lock anyone into any particular low-level API, including OSS Vulkan, simply because we don't know yet what the actual reqs/specs of the next wave of devices will be. Designing WebGPU to be low level API-agnostic is probably safer in this transitional environment.
Not advocating anything here, just thinking out loud.
The truth comes through even in the first part of the sentence containing "Vulkan".
User phire was even more honest(1)
"Everyone here (including me) is upset that Apple are refusing to support Vulkan (or even improve their existing OpenGL support)." "It doesn't really matter that the new API is targeting a completely different market to Vulkan. It doesn't really matter that a WebVulkan can't really exist in the first place. It doesn't matter if this is probally the correct starting point for a NextGen web graphics API." "People just want Vulkan on MacOS and/or IOS."
Blink, WebKit, gecko, etc are implementations that support that standard.
The response wasn't about how Vulkan was good for the web, but rather about how a different route might help the Vulkan ecosystem. That may or may not be good, but it has nothing to do with what's good for the web.
They don't think it's the best way because it hits a fundamental API impedence mismatch with the browser (it's too low level, and probably not the right fit for JavaScript as an API - Vulkan being a standard does not mean we should senselessly emulate it), it's not at all clear the security model matches what the browser actually wants (part of being too low level, but also not being designed with the web's security model in mind), and it requires a lot on the half of users in forms of software support to support 'true' Vulkan as it stands, and it will be difficult to emulate such a low level API and its quirks (it's possibly the lowest level of the 3), which is why WebGPU aims to be a bit higher level. Even on systems like NVidia/Windows with top OpenGL support for years, the variance among OSs, hardware, and cards means e.g. Browsers and developers all implement WebGL in terms of DirectX, not OpenGL, even on suitable platforms. This is simply because the "native" graphics API -- for any platform -- tends to be the one with the most first party support, care, and stability across everything. It doesn't actually matter if you have OpenGL support on Windows, WebGL will still work because of this decision. That means more people can use it. Re-creating this same mistake with Vulkan will likely be costlier, due to it being so much less generic and much more low-level. If we're going to make "WebGL 2.0" happen, whether or not it's actually WebGPU -- it should avoid mistakes like this one.
(It turns out when your software is used by literally billions of people on extremely diverse hardware, sometimes fantasies about driver support from nerds with $2,000 premium machines aren't always true.)
Now that I've said all that: you are now free to continue ignoring literally everything written in the original blog post and ignore everything written by the developers here about its design, and assume whatever you want. That's apparently what people like doing, it seems.