Core Idea
The rail above is thirty years of one API — click through it and a pattern emerges: every era is a fix for the previous era’s bottleneck. One-call-per-vertex drowns the CPU, so geometry moves into buffers; the driver’s fixed menu of lights runs out of looks, so shaders arrive; the desktop API won’t fit a phone, so ES cuts it down; the web has nothing, so WebGL transplants ES into a canvas; and one global state machine fights the multicore era until the explicit successors replace the design outright. OpenGL is the graphics API the rest of this tier descends from — a cross-platform standard old enough that most of computer graphics education was written in its terms. It’s really two things at once: a specification (a Khronos Group document saying what every function must do) and an implementation (written by each GPU vendor, shipped inside the driver). There is no OpenGL library to download — updating your GPU driver is updating OpenGL, which is why driver updates can fix rendering bugs.
The Family Tree
OpenGL (desktop, C API)
└─ OpenGL ES the trimmed cut for mobile/embedded
└─ WebGL 1 ≈ OpenGL ES 2.0, in a browser canvas
└─ WebGL 2 ≈ OpenGL ES 3.0
└─ GLSL its shading language, inherited by all of the above
Everything WebGL is — the state machine, the bind-then-operate rhythm, the two-shader model — it is because OpenGL was; WebGL’s own page tells that API story. The one genuinely new branch grew elsewhere: Vulkan is Khronos’ low-level successor on native platforms, and WebGPU is the web’s equivalent step, sitting above Vulkan, Direct3D 12, and Metal at once.
The rail’s two ends are worth holding together: the 1992 idiom (glBegin, one function call per vertex) and the 2023 one (pass.draw(n), a pre-recorded command) are both “draw a triangle” — everything between them is the industry discovering, one bottleneck at a time, where the work actually belongs: first out of the CPU’s function-call loop, then out of the driver’s fixed menu, and finally out of the driver’s per-call hands entirely.
Where It Stands
OpenGL is in maintenance, not development — the fixed-function era (glLightfv and friends) was deprecated long ago in favor of mandatory shaders, and no major new versions are expected. The platform rivals won their homes: Direct3D on Windows, Metal on Apple (which deprecated OpenGL years ago). The web adds one twist worth knowing: on Windows, browsers run WebGL through ANGLE, translating GLSL to HLSL and routing through Direct3D — historically more stable there than OpenGL drivers, and the usual explanation when a shader renders subtly differently across machines.
Why a Web Developer Should Care
Three practical reasons, none nostalgic:
- The literature speaks OpenGL. The best tutorials, books, and university courses — including the classic matrix and lighting material — are written against OpenGL; the concepts and even most function names transfer to WebGL nearly verbatim.
- The dialect is the same. GLSL knowledge moves freely across OpenGL, OpenGL ES, and WebGL, with only version-syntax differences.
- The pipeline is the pipeline. What OpenGL exposes is the same GPU pipeline every door exposes — learning it once is learning it everywhere.
Connections
WebGL is this API’s browser-shaped descendant and inherits both its powers and its state-machine footguns; GLSL is the language it introduced and the web still speaks; WebGPU is the family’s generational reset. The GPU pipeline is what all of them, differently dressed, have always been doors to.