Shrestha Co

The Evolution of HTML5 Browser Games

4 min readhtml5 · games · web-platform

From Flash portals to plugin-free canvas games to today's installable PWAs — and why the modern answer for a board game is often no canvas at all.

Browser games have been through three distinct eras, and the transitions between them were driven less by graphics than by distribution — who could reach players, and what stood in the way.

Knowing that history is useful, because it explains why the obvious technical choice for a browser game today is often the wrong one.

The plugin era

For roughly a decade, browser gaming was Flash. It gave developers a vector renderer, a timeline, a real scripting language, and — critically — one runtime that behaved identically everywhere. In an era when browsers agreed on almost nothing, that consistency was worth more than any individual feature.

Portals like Newgrounds and Kongregate built enormous libraries on it. An entire generation of designers learned their craft in the Flash IDE.

It ended for reasons that had nothing to do with what Flash could draw. It was a closed runtime with a long history of security vulnerabilities, it drained laptop batteries, and it never worked on the iPhone. Apple's 2010 decision not to support it on iOS mattered more than any technical argument, because it meant the fastest-growing category of devices simply could not run any of it. Adobe ended support at the close of 2020.

The plugin-free era: <canvas> and the HTML5 gap

HTML5 was positioned as the successor, and <canvas> was its centrepiece — an immediate-mode drawing surface with a 2D context, and later WebGL for hardware acceleration.

The capability arrived quickly. Engines like Phaser and PixiJS made 2D games straightforward, and asm.js and later WebAssembly made it possible to compile existing C++ engines to the browser. Unity and Unreal both shipped web targets.

What took longer was everything around the pixels:

  • Audio. The <audio> element was never designed for games. The Web Audio API, with a real node graph and sample-accurate scheduling, took years to land consistently.
  • Input. The Gamepad API, Pointer Events and Pointer Lock arrived piecemeal.
  • Storage. Meaningful local persistence had to wait for IndexedDB.
  • Offline. AppCache was a genuinely broken design, deprecated and replaced by service workers.

By the mid-2010s the platform could technically run games. The distribution story was still worse than Flash portals had been, because there was no equivalent of installation.

The modern era: the platform caught up

What changed in the last several years wasn't the rendering. It was everything else:

  • Service workers made real offline capability possible, replacing AppCache's guesswork with an explicit, programmable cache.
  • Web app manifests made browser games installable — an icon on the home screen, a standalone window, no browser chrome.
  • WebAssembly gave near-native execution for genuinely heavy workloads.
  • WebGPU exposed modern GPU features that WebGL couldn't reach.
  • Trusted Web Activities let the same live web app ship on the Play Store without a port.

The result is that a browser game in 2026 can be installed, run offline, and be distributed through an app store — the three things Flash portals never had — while still being a URL you can text to a friend.

The part that gets skipped: you might not need canvas

Here's where the history becomes practical.

Because canvas was the headline feature of the HTML5 era, "browser game" and "canvas" became synonymous. For a lot of games, that's now a reflex rather than a decision.

Canvas is an immediate-mode surface. You get a bitmap and a drawing API, and everything above that you write yourself: hit detection, scene management, scaling for device pixel ratio, and — the expensive one — accessibility, which canvas has essentially none of by default. A canvas is a single opaque element to a screen reader.

A board game doesn't need any of that. It's a small number of discrete, persistent objects on a grid, changing state a few times a minute. That's a retained-mode problem, and the browser ships an excellent retained-mode renderer already: the DOM.

In OmniPlay every board, token, snake and ladder is inline SVG styled with CSS. No canvas, no WebGL, no game loop. What that buys:

  • Resolution independence for free. SVG is sharp at any device pixel ratio with no manual scaling code — which matters on cheap high-DPI Android screens.
  • Animation the browser optimises. CSS transitions on transform and opacity run on the compositor, off the main thread. A token sliding across the board costs almost nothing.
  • Real accessibility. Every piece is an element. It can carry a label, take focus, be found by a screen reader. On canvas all of that is your problem.
  • Debugging with DevTools. You inspect a token the same way you inspect a button. Inside a canvas you're reading coordinates out of a log.
  • A much smaller bundle, because there's no engine.

The tradeoff is real: past a few thousand simultaneously animating elements the DOM becomes the bottleneck and canvas wins decisively. Particle systems, scrolling shooters, anything with a continuous render loop — use canvas.

But the threshold is far higher than most developers assume, and a Ludo board has sixteen tokens.

The pattern worth taking

Each era of browser gaming was ended by distribution, not graphics. Flash died because it couldn't reach the iPhone. Canvas games plateaued because a URL couldn't compete with an app icon. The current era is interesting because installability and offline finally closed that gap.

Which leaves rendering as an ordinary engineering choice rather than a default. Reach for canvas when the frame rate demands it. For a board game, the DOM is smaller, sharper, more accessible, and easier to debug — and it was there the whole time.