Why LearnOpenGL Outlived OpenGL

OpenGL hasn't shipped a new version since 4.6 in July 2017. Apple deprecated it in 2018 and froze macOS at 4.1. Even Minecraft — the most famous OpenGL application on Earth — announced this February that Java Edition is moving to Vulkan. And yet LearnOpenGL, Joey de Vries' free online book teaching OpenGL 3.3, just spent another day on the Hacker News front page, a decade after it first started collecting them.

That's not nostalgia. It's a signal about a hole in the graphics ecosystem that nobody has managed to fill: the modern APIs won, and none of them has a good front door.

The API died; the curriculum didn't

LearnOpenGL's actual subject was never really OpenGL. The API is the vehicle for a curriculum that walks you from "what is a vertex" through transformation matrices, the camera model, Phong lighting, model loading, framebuffers, shadow mapping, normal mapping, HDR, bloom, deferred shading, and a full physically-based rendering pipeline. Every one of those concepts transfers verbatim to Vulkan, Metal, Direct3D 12, and WebGPU. A GGX specular lobe doesn't care which API submitted the draw call.

De Vries picked OpenGL 3.3 core profile deliberately: it's the version where the modern shader-based pipeline stabilized, and everything after it adds efficiency rather than changing the mental model. That decision, made years ago, is why the book aged so well. It sits at the exact altitude where a beginner can write a main(), open a window, and have a lit, textured spinning cube on screen the same afternoon — while still learning the real pipeline, not a toy abstraction.

Compare the on-ramp for the successors. Vulkan's canonical triangle is on the order of a thousand lines: instance creation, physical device selection, queue families, swapchain management, synchronization primitives, pipeline state objects, command buffer recording. All of that machinery exists for good reasons — explicit control is the point — but it's an initiation ritual, not a lesson. As one graphics veteran put it in the HN thread, the modern APIs "are so incredibly complicated that they will kill any newbie." You can't teach lighting to someone who's still debugging their swapchain recreation on window resize.

What actually changed since the last time this argument happened

This debate re-runs on HN every couple of years, but two things are genuinely different in 2026.

First, WebGPU is real now. As of early this year it ships by default in Chrome, Edge, Firefox, and Safari — Safari 26 and Firefox 141 closed the gap — which makes it the first modern-architecture API with a browser-tab-sized barrier to entry. The WebGPU spec bakes in the concepts OpenGL let you ignore (bind groups, explicit pipelines, command encoding) at a fraction of Vulkan's ceremony. If any API eventually produces its own LearnOpenGL, it'll be this one. It hasn't yet.

Second, the middle layer matured. SDL3 now ships a GPU API that abstracts over Vulkan, Metal, and D3D12, and sokol has been quietly doing the same for years. These are increasingly the right production answer for indie-scale projects — but they're abstractions, and abstractions are where you end up, not where you start. You can't debug a leaky abstraction over a pipeline you've never seen.

The Minecraft migration is the correct lens here. Mojang isn't leaving OpenGL because it stopped working; they're leaving because the driver ecosystem's attention has moved, macOS support is a translation-layer story, and Vulkan is where performance work happens now. That's a statement about shipping software. It says nothing about learning, and conflating the two is the mistake half of every one of these threads makes.

The practical path

Here's the concrete recommendation, and it's the one experienced graphics people keep converging on:

• Learn on LearnOpenGL. Work through Getting Started, Lighting, Model Loading, and Advanced Lighting — roughly the first two-thirds of the book. GLFW plus glad, C++ or C, and every chapter's code is in the companion repo when you get stuck. On a Mac you're capped at core profile 4.1, which means no compute shaders — annoying for the later guest chapters, irrelevant for the core curriculum.
• Then switch vehicles. Once framebuffers and shadow maps are boring, move to vkguide.dev for Vulkan, or wgpu/Dawn if you'd rather learn WebGPU-shaped explicit graphics with less pain. The second API is dramatically easier than the first, because you're only learning the API — the graphics you already know.
• Skip the middle step only if your goal is engine-adjacent work where explicit GPU control is the job. Then eating Vulkan's complexity up front, with vkguide, is defensible. For everyone else it's a motivation shredder.

What you should not do is start with a high-level engine "to learn graphics." Unity and Godot teach you their material systems, not the pipeline. The whole value of this detour is that at the end of it, a frame debugger capture makes sense to you.

The uncomfortable part

The awkward truth the HN thread kept circling is that the industry deprecated its best teaching tool without replacing it. Vulkan has vkguide — excellent, but explicitly aimed at people who already know graphics. WebGPU has scattered tutorials of wildly uneven depth. Nothing in the modern-API world matches LearnOpenGL's combination of scope, sequencing, and polish, which is why a frozen API's tutorial keeps outranking its successors' documentation a decade on.

That gap won't close until someone does for WebGPU what de Vries did for OpenGL: several years of unpaid, obsessive curriculum-building. Until then, the pragmatic answer stands. OpenGL is a dead end for shipping and the best available beginning for learning — and those two facts are not in tension. Learn on the API that teaches; ship on the one that's maintained.