A short history of browser games

History · about 8 minutes to read

A game that runs in a browser tab feels like an obvious thing now. You click a link, something appears, you play, you close the tab. But the web was not designed for that, and the path from a page full of text to a playable board took three decades, two dead plugins and a long argument about who controls the runtime. It is a story worth knowing, partly because it is interesting and partly because it explains why this site is built the way it is.

The web started out as a filing cabinet

The early web was documents. A page was a piece of marked-up text with links to other pieces of marked-up text, and the browser's job was to fetch one and lay it out. There was no notion of a loop running inside the page, no timer, no way to redraw part of the screen sixty times a second. If you wanted something to change, you asked the server for a whole new page.

That constraint produced the first generation of web games, and they were shaped entirely by it. A turn-based game could work: you clicked a link or submitted a form, the server worked out the new state, and it sent back a fresh page with the updated board drawn as a table of images. Chess by correspondence, guess-the-number, text adventures with numbered choices, simple play-by-mail style strategy games — all of these are perfectly happy with one move per page load. Anything requiring reflexes was impossible. Every action cost a round trip over a connection that could easily take several seconds, and the screen flashed white in between.

Applets: the first thing that actually ran in the page

In the mid 1990s the browser gained the ability to host a separate program inside a rectangle on the page, most notably through Java applets. This was a genuine shift. The code ran on your machine, it could keep its own state, it could animate, and it could respond to the keyboard without asking a server for permission. Suddenly a page could contain a real-time game.

In practice it was awkward. The applet was a foreign object embedded in the document rather than part of it: it had its own gray loading box, its own startup delay while the runtime warmed up, and its own idea of fonts and widgets, so it never looked like it belonged. Users needed the right runtime installed and up to date, which many did not have. And because it was a separate program running with real privileges, the security model around it became a permanent source of trouble. Applets proved the idea and then aged badly; over the following years browsers steadily reduced their support for that whole family of plugins, and eventually removed it.

The Flash era

The plugin that actually won the 1990s and 2000s came from a different direction. Flash — created by a small company, later acquired by Macromedia and later still by Adobe — was not built as a programming environment for games. It was built as an animation tool, and its native concepts were a timeline, keyframes, vector shapes and sound. Scripting came along afterward and grew into a capable language, but the tool always felt like a design tool with code attached rather than the reverse.

That turned out to be exactly the right accident. The web at the time had no vector graphics, no reliable audio, no animation model and no consistent rendering across browsers. Flash arrived with all four in one package, and it drew its own pixels inside its own rectangle, which meant your work looked identical everywhere the plugin was installed. Whole ecosystems of small free games grew up around it: portals where anyone could upload a game, sponsorship deals that paid creators for a preloader logo, and an enormous, uneven, wildly creative library of five-minute experiences.

What Flash got right

Two things, and both were about people rather than technology. First, one runtime everywhere. A creator could build once and be reasonably confident it would run the same on any desktop, which is something web developers of the era did not otherwise enjoy. Second, and more important, the barrier to entry was low in an unusual way: the tool was visual, so an artist with no engineering background could draw a character, put it on a timeline, add a few lines of script and have a playable thing. An entire generation of game developers learned by making tiny Flash games nobody paid them for, and many of them went on to build much larger games elsewhere. That pipeline mattered more than any individual title.

What Flash got wrong

It was proprietary, and that was structural rather than incidental. The runtime came from one company, the authoring tool came from the same company, and the format was theirs. When a single vendor controls the way a large part of the web is delivered, everyone else is a tenant. It was also a persistent security problem: a large binary plugin with deep system access, installed on nearly every desktop, updated on its own schedule, is close to a perfect target, and it was treated as one for years. Users learned to associate the update prompt with risk.

And it behaved terribly on phones. It was designed around a mouse pointer that could hover, a keyboard, a fixed window size and a machine plugged into the wall. Touch input, small screens and battery life were all afterthoughts, and the mobile versions that existed were slow and drained power. When the web's center of gravity moved to handheld devices, Flash could not move with it.

The pivot: the browser learned to do it itself

Several things happened close together in the late 2000s and early 2010s, and together they removed the reason to use a plugin at all.

Smartphones arrived and, crucially, the most influential of them never supported Flash at all. That single decision meant that any site wanting to reach phone users needed a plugin-free version, and "plugin-free" quickly stopped meaning "no interactivity."

Browsers gained the <canvas> element: a rectangle you can draw into from JavaScript, pixel by pixel or shape by shape, as often as you like. That is the minimum requirement for a real-time game, and it was now part of the page rather than a foreign object inside it. At the same time JavaScript engines went through a period of ferocious competition between browser makers, and the language went from something you used to validate a form to something fast enough to run a game loop. The gap between plugin performance and page performance closed, then reversed.

The rest of the platform filled in around it. A proper audio interface replaced the old trick of hiding a media player somewhere on the page. A gamepad interface let the browser see controllers. Request-animation-frame gave games a way to draw in step with the display instead of guessing with timers. Local storage let a game remember your best score with no account and no server. By the middle of the 2010s, everything Flash was originally needed for was available directly in the page, in an open format, with no installer.

The end of Flash, and what went with it

Support was withdrawn gradually and then all at once. Browsers began asking permission before running plugin content, then blocking it by default, and around the end of 2020 the runtime reached the end of its life and browsers removed it entirely. From a security standpoint this was unambiguously the right call.

From a preservation standpoint it was a catastrophe with a specific shape. Enormous libraries of small games — the work of thousands of hobbyists, much of it never published anywhere else, much of it the only copy — became unopenable in a single browser update. This was not like an old console game where the cartridge still exists in someone's attic. In many cases the file still exists on a server but nothing on a normal computer will run it, and the source project it was built from is long gone. A large slice of a genuinely important creative era went from "one click away" to "requires special software" almost overnight.

The response has been better than you might expect. There are emulators that reimplement the old runtime as ordinary web code, so a preserved file can be played in a modern browser with no plugin, and there are archives that collected what they could before the deadline. Coverage is partial: some games work perfectly, some run with glitches, and anything that depended on a vanished server will never fully work again. It remains one of the clearest lessons the web has produced about what depends on a single vendor's willingness to keep shipping a binary.

Where things stand now

Two capabilities changed the ceiling. WebGL gave pages access to hardware-accelerated 3D graphics through an interface close to the one native applications use, and WebAssembly gave them a compact, fast compilation target for code written in languages other than JavaScript. Between them, large commercial game engines can now export to the browser, and the result is that "browser game" no longer describes a size or a genre. It can mean a 20 kB puzzle written by one person in an afternoon, or a full 3D title with an hour-long download and a loading screen.

Meanwhile the casual audience that Flash portals served largely moved to app stores. The install, the icon on the home screen and the push notification turned out to be commercially powerful, and most short-session play now happens inside apps. Browser games did not die, but they stopped being the default place people go to waste ten minutes.

Why the small end still matters

This is our own position, so read it with that in mind. A game written in plain HTML, CSS and JavaScript has properties nothing else on the list has.

• No install step. No download, no permissions dialog, no account. A link is the whole distribution mechanism, which also means someone can share a specific game with a friend and the friend is playing four seconds later.
• No runtime to maintain. There is nothing to keep up to date, nothing to patch and nothing that can be switched off by a vendor, because the browser itself is the runtime.
• It loads on a bad connection. A page of this size arrives in about a second on a weak mobile signal, and once the browser has cached it, going back to it is close to instant even if the network is having a bad day.
• It will still work in a decade. This is the real argument. Standard HTML, standard CSS and standard JavaScript are supported by every browser and are maintained with strong backward compatibility. Code that uses nothing proprietary has nothing to be abandoned by.

The honest trade-off

You give up scale. Hand-written games in a page are not where you go for heavy 3D, for a hundred megabytes of art and audio, for physics simulation across thousands of objects, or for the kind of content pipeline that a large team needs. There is a real reason big projects reach for an engine, and it is not laziness. The small approach buys durability and speed by accepting a limit on ambition, which is a good bargain for a puzzle and a bad one for an open world.

How this site fits into the story

Every game here is written by hand for this site. There is no third-party game frame, no embedded player from another domain, no engine export and no external script deciding what you see. Each game is a page, a stylesheet and a small script, which is why the pages are quick and why they behave the same in every browser we can test.

That choice is a deliberate echo of the good part of the Flash era without the part that ended it. The good part was small games made by identifiable people, playable in one click, with no ceremony. The part that ended it was depending on someone else's plugin to deliver them. Writing directly to the platform keeps the first and avoids the second, and it means that if this site sits untouched for years, the games will still open.