[pjmlp]

It is not being dishonest as alternative APIs don't suffer from extension explosion.

Also I don't believe that by following this path Vulkan will be any better than OpenGL, ES, WebGL.

Let's see how many Vulkan 2.0 will have and of what kind.

[exDM69]

Yes, yes it is. If the extensions would be anything like the OpenGL extensions which make changes to the core api functionality, you'd be right. But take a look at the extensions and tell which one(s) would cause a "write once, port everywhere" situation.

I can't name a single extension that would be causing any friction in Vulkan, unlike OpenGL where there's lots of code paths that need to be implemented to do even basic stuff (and all the core/ARB/EXT variations).

Yeah, Vulkan has some extra complexity stemming from being cross-vendor and designed by a commitee. But it's nowhere nearly as bad as you imply.

In my experience with Vulkan, it's all the optional features and device capabilities that need to be queried at runtime and decisions made based on that that's causing complexity with portability (you don't need to care about most of the extensions, and the ones you do have to care about are simpler than their OpenGL counterparts, ie. WSI vs. GLX/WGL/EGL). And apart from a few pain points (like numbers of queues exposed), it's relatively straightforward and comparable to D3D or Metal in complexity.