> To anyone who has ever spent time working on a platform API this is deeply insulting.

I've worked on platform APIs too. Maybe "almost no cost" wasn't the right phrase, but there's certainly less cost for the platform vendor.

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

It's a tradeoff that has to be evaluated on a case-by-case basis. So far I haven't seen arguments for WSL that are compelling enough.

My critique on all of these remains largely the same since we tried doing WebCL:

-- Path 1: We do need a leap here, and that leap should be essentially unleashing GPGPU primitives (memory barriers, etc.). The web is a ~decade behind, when we have a chance to 10X+ over what regular apps do.

-- Path 2: If not, then pure conservative standards work a la webgl2. Useful, and should take care for politicking to not prevent Path 1 from happening in parallel.

It's disconcerting for, ~7 years later, the same problems to keep happening.

They have to implement the existing API or their own. The cost will be the same for both cases. For big platform vendors, almost no(extra) cost.

On the other hand, we, the ordinary developer must pay the cost of supporting N APIs on M platforms. Every APIs carelessly invented by vendors just because almost no extra cost burden us all.

Hence middleware engines, with productive high level APIs, while using every feature across all boards, without having to deal with messy extensions.

AMDN and Khronos are still fighting to get the love of CAD industry, adding back OpenGL features, because after having to create Iris Inventor like APIs in-house, they aren't keen in switching to yet another low level API.

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

I’m one of the most vehement proponents for the use of platform-specific UI toolkits here, but even I disagree with that this statement without qualification. Standards, in general, are a useful thing to have. We’ve occasionally seen (for example, in the case of application frameworks) that each platform doing their own thing has now made it so that the better experience for the user is the non-general API. But standardized interfaces (POSIX, OpenGL, JavaScript) when done right have been a boon for developers and end-users alike.

All those standards are good examples of write once, debug everywhere, implement multiple code paths tailored by bugs, OEM specific features and workarounds.

Making the end result in industrial code bases hardly much different from implementing multiple times.

This seems a somewhat ill-informed comment, since you shouldn't be thinking of something like Vulkan as a platform API in the first place. Vulkan (and most other APIs, e.g. OpenGL) is an almost entirely platform-independent API targeting modern GPUs. There are a small number of platform-dependent entry points for window system interaction and such like, but their surface area is a very small percentage of the overall API since GPUs are such complex beasts.

And it shows, given the lack of tooling versus what platform APIs offer out of the box.

Instead of a modern API, frameworks, 3D model format, IDE support for debugging shaders, we get plain old C, extensions creep, and go search yourself for basic feature like displaying text or loading textures.

Hardly an improvement on OpenGL status quo.

OK, of the criticisms of Vulkan I've heard, "it doesn't have a function for display text" is the weirdest one. I would be upset if Khronos did include a function for displaying text, because it would invariably be broken in numerous ways.

That attitude is why plenty of graphical developers rather adopt platform APIs instead, because we get the full package for anything graphics related, instead of learning to make fire with sticks.

I did my graduation thesis in OpenGL, hunting for libraries that kind of work together, and doing from scratch what every other OpenGL beginner has to go through, is no fun.

Every Vulkan book does the same, first set of chapters are tips about which libraries to hunt for.

The dark side allows for a better gratification on time to pixel, instead of rites of passage.

Something that Khronos has failed to learn with OpenGL and their Vulkan SDK proves that they didn't actually learn their lesson.

If Vulkan SDK was actually at the same level as DirectXTK, Metal Kit, 3DS SDK, PhyreEngine,GX2... maybe it would get more love from those us that rather embrace the dark side.

WebSQL wasn't a mistake.

It make an enormous amount of existing code available on the web.

It just wasn't agreed to by Firefox because it didn't have enough JS.

It wasn't agreed on because it was not standardized and most importantly, because there were no alternative implementations. SQLite is amazing but accepting a single implementation as standard is a huge dependency. I was very sad to see it getting dropped but it had to be.