It has been a year since WebVulkan was last discussed on this mailing list, and I think, now that a specification of Vulkan is out, it's time to revisit this.

The end of OpenGL/ES

Vulkan is the successor to OpenGL and ES. There isn't going to be an OpenGL 5, and an ES 4 seems doubtful.

Vulkan, formerly named the "Next Generation OpenGL Initiative" (glNext),[38][39] is a grounds-up redesign effort to unify OpenGL and OpenGL ES into one common API that will not be backwards compatible with existing OpenGL versions.[40][41][42] The initial version of the API was released on 16 February 2016.

Wikipedia

It'll be a while before this becomes a persistent pain for web developers, but as the years pass (as they're wont to do), this is going to become a bigger burden.

The difficulty of Vulkan

Vulkan is a very complex API, and it is also largely discoverable and extensible. It exposes a wide variety of machine parameters and capabilities, and fully expects every developer to intricately be aware of those and use them to the best advantage.

That is to say, it's not a beginners API. Even Khronos advises beginners to learn OpenGL of some or other variety first, before attempting Vulkan.

Many want WebVulkan

There does exist a growing clientele for this kind of API (the difficult kind) on the web, which is the variety of companies and developers that have coalesced around WebGL and are ready to jump into new waters. We're all eagerly waiting for WebGL2 (limited as it may be), and we can't wait for WebGL the ES 3.1 version, mainly because of compute capabilities.

Vulkan or irrelevance

Right now the API gap to vulkan from the Web is so large, it might not seem to matter much to think about it. But if the hardware accelerated web intends to stay relevant, Vulkan can't be ignored. It's there, it's increasingly going to be what people expect to be able to do, and as the Vulkan ecosystem matures, the web will be left behind, again.

We can't afford to ignore Vulkan. For the hardware accelerated, web, it's Vulkan or nothing.

Resistance is futile

Vulkan isn't just a graphics API. It's an API to build an ecosystem on. There is already a wide variety of tools designed to tie into that ecosystem (from SPIR-V compilers to abstraction frameworks, debuggers, etc.).

It would be an immense disservice to the Web if we tried to be different... because reasons. We'd be excluding ourselves from all the efforts that tie in with the Vulkan ecosystem.

It's also extremely doubtful that a Web-only hardware accelerated solution could ever gain multi vector traction, as any such effort has persistently failed in the past.

Re: [Public WebGL] WebVulkan