It doesn't really make sense to have Khronos maintain nice high-level libraries. There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place. Their commitee/standard-based process works for specs, but I don't think it will work very well for the needs of day-to-day application programmers.
Why do you need Khronos to "bless" a particular library anyway?
Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.
> It doesn't really make sense to have Khronos maintain nice high-level libraries.
I guess we'll have to agree to disagree on that.
> There's no evidence they'd be good at it and if you look at their GitHub, they're not particularly good at maintaining actual codebases in the first place.
Well that's another complaint then, but it doesn't detract away from my initial complaints.
> Why do you need Khronos to "bless" a particular library anyway?
Because now we're going to have a million different wrapper libraries to do everything, or you're going to be stuck with the absurd Vulkan API. It was already annoying enough that you had to have different wrappers to abstract the GUI components, now people have to have another mediocre abstraction in addition to the GUI crap.
I suppose you could argue "that's fine", and you're free to have that opinion, but I think it's worse
> Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.
They're not doing new versions of OpenGL. Yes, the drivers will support them for the foreseeable future but they will get increasingly out of date.
>now we're going to have a million different wrapper libraries to do everything, or you're going to be stuck with the absurd Vulkan API.
The more things change...
Fact is that most people will never directly touch such things unless they are a) a graphics programmer at a handful of companies or b) someone like this author doing something more for education than to produce raw business value. our "high level libraries" are Unity and Unreal if you're makinig a game (and some smaller engines), and BGFX et al. if you're making your own small engine. The work is already done without Khronos lifting a finger for implementation.
the recipients of a) are the ones who asked for more control. They are paid pretty well so they have plenty of time to grok the specs compared to a small time creator, so rapid prototyping isn't prioritized.
Why do you need Khronos to "bless" a particular library anyway?
Also they didn't get rid of OpenGL. You can still use it. It will probably be the most widely supported graphics API for a long time.