Canvas, WebGL, and then WebAssembly

Three technologies replaced one: how the browser learned to run games without asking permission first.

The Plugin Was the Product

Flash worked because it was a sealed box. Adobe's runtime installed once, sat in the browser as a trusted guest, and thereafter executed its own bytecode with no negotiation required from the host environment. That arrangement gave developers a consistent, high-performance target across operating systems; it also meant that one company — Adobe — owned the ceiling. When the plugin era ended on 31 December 2020, the ceiling did not simply move: it dissolved, replaced by a set of open standards that behave very differently from anything a plugin ever was.

The three technologies that filled the gap — Canvas, WebGL, and WebAssembly — are not a tidy succession. They arrived at different times, solved different problems, and are in daily use simultaneously. Understanding them separately, and then together, explains why browser games in the 2020s look and perform as they do, and why the distribution model changed as fundamentally as the graphics pipeline.

Canvas: The First Floor

The HTML Canvas element arrived in browsers in 2004, initially proposed by Apple for use in Safari and then standardised through the WHATWG HTML living standard. Its 2D rendering context gave JavaScript direct access to a pixel buffer inside the page: draw a rectangle, composite an image, clear and redraw sixty times a second. The model was immediate-mode rendering — no scene graph, no retained objects — which made it fast for simple cases and demanding for complex ones, because the CPU was doing everything.

For casual games — puzzle tiles, card layouts, simple platformers — Canvas 2D was sufficient, and it arrived early enough to give developers a usable alternative while the plugin debate was still running. Developers who had been writing ActionScript inside Flash found that the 2D Canvas API asked for similar thinking: sprites, layers, a game loop driven by requestAnimationFrame. The transition was laborious but conceptually legible. Several JavaScript frameworks, including the open-source Phaser engine, built their abstraction layer directly on top of the 2D context, and those frameworks now underpin a large portion of the casual browser game market.

The ceiling, however, was the CPU. A Canvas 2D scene with hundreds of moving elements and real-time lighting effects simply saturated the processor in ways that Flash — which had its own internal renderer with partial GPU access in later versions — had not.

That ceiling made 3D browser games essentially impossible at Canvas 2D quality, and it pushed the standards process toward the GPU.

WebGL: The Graphics Card Enters the Room

WebGL is a JavaScript binding to OpenGL ES, the embedded-systems variant of the OpenGL graphics standard. The Khronos Group, the industry consortium that maintains OpenGL, published the first WebGL specification in 2011, and WebGL 1.0 reached the Khronos registry as a standard that browsers could implement without any plugin whatsoever. The key difference from Canvas 2D is the execution site: WebGL shaders run on the GPU, not the CPU. Geometry, lighting, and texture operations that would have paralysed a JavaScript thread complete in milliseconds on dedicated graphics hardware.

For browser games, this was the shift that made three-dimensional worlds viable at playable frame rates. Engines that had previously required a plugin — Unity being the most commercially significant example — began building WebGL export pipelines. Unity's WebGL build target, introduced in a meaningful form around 2015, let studios compile their existing game logic into a form the browser could execute directly. The result was that titles with asset budgets and visual complexity previously associated only with installed clients began appearing in-browser without installation.

WebGL also changed the competitive geography. South Korea, which had built a large online gaming industry around PC-café infrastructure and fast broadband, had developed games that ran as lightweight clients precisely because bandwidth and café hardware were reliable quantities. A game that could be linked, shared, and launched in thirty seconds, with no installation step interrupting the moment, had a different user-acquisition dynamic from one that required a gigabyte download.

The web now offered a different kind of frictionless access — no client download, instant entry from any device — and studios globally began designing toward it.

WebGL 2.0, based on OpenGL ES 3.0, extended the specification with compute-adjacent features and wider texture format support, and is itself now superseded in the forward-looking roadmap by WebGPU — a new API designed around modern GPU architectures rather than the OpenGL lineage. WebGPU is not yet universally supported, but its trajectory is clear: the browser's graphics API will continue to track the GPU industry's own evolution, without any intermediary company controlling the path.

WebAssembly: The Performance Floor Rises

Canvas and WebGL addressed graphics. WebAssembly addressed computation. The problem it solved is precise: JavaScript is a dynamic language interpreted at runtime, and while modern just-in-time compilers have made it dramatically faster than its early reputation suggested, physics simulation, pathfinding across large graphs, audio DSP work, and complex game-state calculations still ran slower in JavaScript than in compiled native code. For games with demanding logic, this was the remaining argument for installed clients.

WebAssembly — Wasm in shorthand — is a binary instruction format designed as a compilation target. Code written in C, C++, Rust, or other compiled languages can be compiled to Wasm and executed inside the browser at near-native speed. The W3C standardised WebAssembly in 2019 as an official web standard, making it part of the same standards stack as HTML and CSS rather than a vendor extension. Every major browser implemented it, which meant that a Wasm module deployed to the web ran consistently across Chrome, Firefox, Safari, and Edge without the compatibility variance that had historically plagued browser-targeted code.

The practical consequence for game development is that an engine codebase — the physics solver, the renderer's scene management, the audio mixer — can be compiled once to WebAssembly and run in the browser at performance levels that make the CPU argument against browser games largely obsolete. Unity's and Unreal Engine's WebGL export pipelines both compile their core runtime to Wasm. Emscripten, the open-source compiler toolchain that translates C and C++ to Wasm (and previously to a JavaScript subset called asm.js), was the critical engineering bridge that made this practical before the standard was fully ratified.

What the Shift Actually Changed

Three features define what the post-plugin model produced, taken together. First, there is no installation step and no trust decision from the user: Canvas, WebGL, and Wasm are part of the browser, not a guest inside it. Second, the performance ceiling is no longer controlled by a single vendor; it tracks open standards bodies — Khronos, W3C, WHATWG — whose membership includes browser makers, hardware manufacturers, and major software companies, none of whom can unilaterally end support in the way Adobe ended Flash support on a date of their choosing. Third, the distribution model that depended on portals and plugins — the aggregation of games behind a single branded destination — lost its technical rationale. If any URL can host a WebGL game and any modern browser can run it, the portal's value had to be editorial rather than infrastructural, and most portals found that a weaker proposition than they needed.

The replacement technologies did not restore what Flash was. They built something structurally different: not a runtime owned by a company but a capability owned by the web itself, slower to update, governed by committee, but also impossible to sunset with a press release.