Skip to content
Dev Tools Article

OpenGL Is Dead. Learn It Anyway

A frozen API keeps topping Hacker News because no modern graphics API has earned its classroom yet.

Lenn Voss
Lenn Voss
Cloud & Infrastructure Writer · Jul 23, 2026 · 4 min read
OpenGL Is Dead. Learn It Anyway

A tutorial site for a graphics API that hasn't had a new release since 2017 climbed the Hacker News front page again this week. That's not nostalgia. LearnOpenGL, Joey de Vries' free, book-length course on modern OpenGL, keeps resurfacing because the industry has a problem it doesn't like to admit: we deprecated the API everyone learns on, and a decade later we still haven't replaced the classroom.

The API time forgot — that still runs everywhere

On paper, OpenGL is done. The final version, 4.6, shipped in July 2017, and Khronos has spent the years since pouring its energy into Vulkan. Apple deprecated OpenGL outright in macOS Mojave back in 2018 and froze its implementation at 4.1. No new features are coming, ever.

And yet OpenGL code runs on more devices today than at any point in its history. Mesa's Zink driver implements GL on top of Vulkan; ANGLE translates GL ES to Metal, D3D, and Vulkan and underpins every WebGL page in Chrome. The API survives as a compatibility layer precisely because so much software — CAD tools, emulators, indie games, half of academia — still speaks it. "Deprecated" turned out to mean "frozen and universally emulated," which for a learner is a surprisingly comfortable place: the target has stopped moving.

Why the classroom hasn't moved

The honest reason beginners still get pointed at a frozen API is boilerplate math. With OpenGL and GLFW, a textured, shaded triangle is an afternoon and maybe a hundred lines. The canonical Vulkan tutorial takes on the order of a thousand lines to reach the same pixel, because Vulkan hands you everything OpenGL's driver used to hide: memory allocation, synchronization, swapchain management, pipeline state compiled up front. That's exactly what makes Vulkan great for engine developers and brutal for someone who doesn't yet know what a depth buffer is. Even the author of vkguide.dev — one of the best Vulkan resources around — argued in this week's HN thread that modern APIs will "kill any newbie on the spot," and that OpenGL is where you pick up the vocabulary first.

The other reason is that nothing else has LearnOpenGL's completeness. The site walks from a window and a first shader through shadow mapping, normal mapping, HDR, bloom, deferred shading, and SSAO, all the way to a physically based rendering pipeline with image-based lighting — then makes you ship a small 2D game. It's been revised continuously for roughly a decade, it's free (with an optional print edition), and every chapter builds on runnable code from the last. Vulkan has good tutorials; WebGPU has promising ones. Neither has a single resource that takes you from zero to PBR with that kind of editorial coherence. Pedagogy compounds over ten years the same way code does.

What transfers, and what you'll unlearn

The pragmatic case for starting here is that most of what LearnOpenGL teaches isn't OpenGL. Vertex layouts, the rasterization pipeline, texture sampling and mipmaps, framebuffers, tone mapping, the microfacet math behind PBR — that's the actual discipline of real-time rendering, and it's identical in Vulkan, Metal, WebGPU, and whatever comes next. GLSL knowledge carries almost directly into WGSL and HLSL. When a Vulkan tutorial says "descriptor set," you'll survive because you already understand what a uniform is for.

What doesn't transfer is OpenGL's personality: a global state machine where glBindTexture silently changes what the next call does, and a driver that hides synchronization entirely. Modern APIs bind resources explicitly and make you own the timeline. Treat those habits like a physicist treats Newtonian mechanics — a simplification you'll consciously discard later, not a lie that ruins you.

One real trade-off deserves flagging: on a Mac you're stuck at GL 4.1, which predates compute shaders (a 4.3 feature). The core chapters work fine, but the compute-shader material won't run natively — Apple Silicon users should plan to do that leg of the journey in Metal or WebGPU instead.

The 2026 path

Here's the route I'd actually give a colleague starting today. Work through LearnOpenGL at least through the Advanced Lighting section — that's where rendering stops being API calls and starts being ideas. Then port one project, not to Vulkan first, but to WebGPU: as of late 2025 it ships enabled by default in Chrome, Firefox, and Safari, and via wgpu or Google's Dawn it doubles as a sane native API. WebGPU gives you explicit binding and modern pipeline structure without Vulkan's fifty-lines-to-allocate-memory ceremony, which makes it the ideal second API — and, once its tutorial ecosystem matures, the likely heir to LearnOpenGL's role entirely. Go to raw Vulkan only if you're aiming at engine or driver work, where that control is the job description.

The uncomfortable takeaway for the graphics community is that a frozen API remains its best on-ramp because nobody has invested ten patient years in documenting a modern one to the same standard. Until someone does for WebGPU what de Vries did for OpenGL, the front page will keep rediscovering this site — and it'll keep deserving it.

Sources & further reading

  1. Learn OpenGL, extensive tutorial resource for learning Modern OpenGL — learnopengl.com
  2. Learn OpenGL, extensive tutorial resource for learning Modern OpenGL - discussion — news.ycombinator.com
  3. WebGPU is now supported in major browsers — web.dev
Lenn Voss
Written by
Lenn Voss · Cloud & Infrastructure Writer

Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading.

Discussion 1

Join the discussion

Sign in or create an account to comment and vote.

Cora Diaz @cloudnative_cora · 1 hour ago

totally get this. we migrated a real-time event pipeline off glsl compute shaders to wasm + webgpu last year, and the learning curve was brutal partly because there's no cohesive mental model for it yet like opengl had. frozen apis are annoying, but they're also predictable, and that matters when you're trying to teach fundamentals without chasing moving targets.

Related Reading