How browser games stopped needing plugins
For about fifteen years, "browser game" meant Flash, a plugin bar, and a security update you kept postponing. Then the browser absorbed everything the plugins did and the whole category quietly reinvented itself. Here's what actually changed.
If you played games on the web in the 2000s, you played them inside something that wasn't really the web. The page was a container; the game lived in a plugin — Flash, mostly, and Java applets, Shockwave and Unity's web player around the edges. The browser's job was to hand a rectangle to another piece of software and get out of the way.
That arrangement was enormously productive and structurally doomed, and understanding why explains a lot about what browser games look like today.
What the plugin era got right
It's easy to be sniffy about Flash now, but it solved problems the web genuinely couldn't. It drew shapes fast, played audio reliably, ran the same on every machine, and — crucially — it came with an authoring tool that let people who couldn't program make things that moved. An enormous amount of the internet's creative energy went through that tool.
The browser at the time could do essentially none of this. There was no way to draw arbitrary graphics; you positioned images with CSS and hoped. Audio meant an embedded player. Animation meant a timer and a lot of praying. If you wanted a game, a plugin wasn't a workaround, it was the only door.
What killed it
Three things, roughly in order of importance.
- Phones. The iPhone shipped without Flash and never added it. Overnight, a large and growing share of the audience simply could not run the dominant format. Nothing else on this list would have mattered as fast.
- Security. A plugin is a second, separately-updated program with deep access, running content from strangers. That's a hard thing to make safe, and the update treadmill became a genuine burden for everyone.
- The browser caught up. This is the part that's easy to miss, because it happened gradually and without a launch event.
The three pieces that replaced it
What the modern browser gives you is not one Flash-replacement but a handful of unglamorous primitives that together cover the same ground.
A canvas to draw on
The <canvas> element is a rectangle of pixels and a drawing API — lines,
shapes, images, text, transforms. It sounds almost too basic to build a game on, and that's
exactly its virtue: it does nothing you don't ask for, and it's fast. Every game on this site
is ultimately drawing into one.
Alongside it, WebGL exposes the graphics hardware directly for the cases where a 2D API isn't enough — thousands of moving objects, real lighting, shader effects. Our mining game Strata runs on WebGL, because it's shifting a great deal of tile and lighting work per frame; several of the smaller games are happier on plain 2D canvas.
Sound that can be built rather than played
The Web Audio API is the piece people underestimate. It isn't a music player — it's a small modular synthesiser. You can create oscillators, filters and envelopes and wire them together at runtime, which means a game can generate its audio rather than shipping files.
That's not just a size saving, though downloading no audio at all is a real advantage for a game that has to start in two seconds. It means sound can respond continuously to the game state — a score whose key darkens as you descend, an engine note tied to actual speed, a collision whose timbre depends on what you hit. Several of our games have no audio assets whatsoever; the soundtrack is code.
A frame timer that respects the machine
The unglamorous hero is requestAnimationFrame, which lets the browser tell your
game when to draw instead of your game guessing. It syncs to the display's refresh rate,
throttles when the tab is hidden, and generally stops games from cooking laptop batteries in
background tabs. Before it, everyone used a timer and every game was subtly wrong on hardware
the author didn't own.
What we lost
It would be dishonest to present this as pure progress. The plugin era had an authoring tool and the modern web does not. Flash let a person with drawing skills and no programming background make something genuinely good; today's equivalent path is a game engine with a learning curve, or writing code. The barrier to entry for a certain kind of creative person went up, and a lot of the messy, prolific, amateur energy of the old web went somewhere else.
We also lost a distribution model. Flash games were files that portals hosted and players traded. Modern browser games are services on someone's domain, and when that domain lapses the game is gone. A striking amount of the Flash era survives only because volunteers built emulators to preserve it — which is more than will likely be done for most of what replaced it.
What it's actually like to build one now
Better than you'd guess, with one persistent annoyance.
The good part is that the platform is genuinely capable and there's no install step for anybody — not for the player, and not for us. A game is a page. It updates when we deploy. It runs the same on a decade-old laptop and a phone. For the kind of quick arcade games we make, the browser isn't a compromise against a native app; it's straightforwardly the right target, because the entire value proposition is "you're playing within three seconds of being curious".
The annoyance is input. A game that assumes a keyboard excludes phones; a game that assumes touch feels wrong on a desktop. Most of our titles are built one-button or one-thumb specifically so the same control scheme works everywhere without explanation — there's a whole guide on why that constraint turns out to be a gift. The exceptions are honest about it: Strata needs a keyboard for directional digging and simply says so.
Audio autoplay is the other recurring tax. Browsers won't let a page make noise until the user has interacted with it, which is entirely correct and means every game needs a "click to start" that exists partly to unlock the sound.
Where it's going
The interesting direction is WebGPU, which exposes modern graphics hardware far more directly than WebGL managed, and WebAssembly, which lets games written in other languages run in the browser at close to native speed. Together they make "a serious game, in a tab, with no install" a much less surprising sentence than it was.
For small arcade games, though, none of that is the bottleneck. Canvas and Web Audio were already more than enough a decade ago. What actually changed for us isn't capability — it's that a game can now be a link you send someone, and it just works, on whatever they happen to be holding. That was the plugin era's real promise, and it took the plugins going away to deliver it.
→ Play our browser games · → The arcade classics that inspired them