> The hard part of learning OpenGL for me has been the sheer amount of boilerplate needed to get the most basic image on the screen.
You think that now, but wait until you get to Vulkan.
You think that now, but wait until you get to Vulkan.
But here's the way I look at it: OpenGL was created to abstract over graphics hardware and operating systems both at once, and yet was intended to be high-level enough that it could be called out to directly by application developers (including game developers).
It was what people needed at the time, but I think it was trying to do too many things in a single layer of abstraction, and these days it isn't doing a great job at any of them. It's known for being slow. Most people don't write it directly anymore; they use a game engine or library and only write shaders directly. It performs inconsistently between OSes.
Whereas Vulcan, and even more so Metal, are decidedly lower-level. They abstract over the hardware and that's about it. This enables the higher-level libraries and engines that people were already using to be more fine-tuned and performant while still allowing graphics hardware to remain a commodity.
In this context WebGL is interesting because it's also an abstraction over Vulcan/Metal/DirectX, while remaining lower-level than most of those other libraries and engines. It's really very much like we've split the OpenGL layer in two and ended up with one layer focused on performance within a given OS, and another layer focused on providing a modern, ergonomic API across all systems.
All in all, I think this is a pretty good way for things to have progressed.
I'd still hesitate to say that Vulkan, DirectX, and Metal are lower level in any meaningful way. Most of the work the driver does/did, like shader/pipeline state compilation or command submission, is still there. Vulkan and DirectX just tie the driver's hands a bit, for better or worse inversely proportional to how good the driver stack is/was. Calling Vulkan lower-level than OpenGL is a bit like calling Java lower level than Javascript. We're still a long way from being able to shoot ourselves in the foot like we can with C.
Unless you're using the more modern features of Metal like argument buffers and manual resource tracking, Metal is closer to late-stage OpenGL than it is to Vulkan or DirectX. Otherwise, they're about the same.
I agree about the split between performance vs ergonomics, but it's a bit more complicated than that. Conceptually, the lower-level APIs expose functionality that make graphics programming much, much easier for large scale rendering engines. It's not just about performance. Most of the initial boilerplate amortizes away behind an abstraction layer anyway. What's exposed in web apis is still many years behind the state of the art in the native space. However, when it comes to just drawing a triangle with the techniques of 2010, personally I have a lot of hope for WebGPU. Besides functionality, the ergonomics problem of native apis are primarily down to tooling. Large game studios and engine devs can afford to invest in infrastructure that small hobbyists/indie devs can't.
Its a little surprising there's no real movement for an API that is closer to ES3 in difficulty that targets Vulkan and Metal underneath. I guess maybe webgpu will be that thing eventually.
I can run pretty much the same software on my desktop today as on my now-dead 2008 laptop.
On the CPU.
But the GPU is capped at OpenGL 2. What's the point of being a software enthusiast if the software is tied to the most expensive piece of hardware in the box?