I built my first browser game in 2004 — a side-scrolling shooter with a spaceship firing pixelated lasers at descending aliens. Flash MX 2004, .swf file, <object> tag, uploaded to Newgrounds. Within a week: 12,000 plays. It felt like magic.
What I didn't realize: I was building on borrowed ground. Flash was owned by a single company — Macromedia, then Adobe. Every game I made depended on a plugin that could be killed by one corporate decision. In 2010, it nearly was. The browser game industry didn't just survive. It came out stronger — open, standardized, faster. Here's how that happened.
The Flash Empire: 1996–2010
By 2008, Flash Player was on 98% of internet-connected desktops. It ran identically on Windows, Mac, and Linux with a mature IDE — timeline, vector tools, ActionScript. Draw art, animate it, write logic, output a .swf. For game developers, this was unprecedented. Before Flash, the web meant Java applets or Shockwave. Flash gave us clean vector graphics, a consistent runtime, and portals — Newgrounds, Kongregate, Armor Games, Miniclip — that could put a game in front of millions within hours.
Between 2005 and 2010, the Flash scene was genuinely vibrant. The Last Stand, Fancy Pants Adventure, Bloons TD, Boxhead — these defined what a browser game could be. Developers pulled in serious money through sponsorship deals: a portal would pay a few thousand dollars to put their logo on your game. Some earned six figures annually.
But the foundation was rotting. Flash's runtime was a security sieve. On Mac, it drained laptop batteries in under an hour. And on mobile — the platform about to eat the world — Flash simply didn't work.
The Letter That Changed Everything
In April 2010, Steve Jobs published "Thoughts on Flash" — an open letter explaining why Flash would never run on iOS. Proprietary, insecure, battery-draining, mouse-dependent. Jobs argued for HTML5, CSS3, and JavaScript as the replacement.
I read that letter and felt panic mixed with relief. Panic because my entire skill set — years of ActionScript and the sponsorship ecosystem — was on a clock. Relief because I'd been fighting Flash's performance ceiling for years. The letter didn't kill Flash overnight — Adobe shipped Flash Player 11 in 2011 with Stage3D, a GPU API that arrived years too late. But by 2015, Chrome was blocking Flash content by default. Adobe set the end date: December 31, 2020.
The Canvas Emerges: 2011–2015
What Jobs's letter did, more than anything, was accelerate work that was already underway. The HTML5 specification had been in development since 2008, and the <canvas> element — a blank rectangle you could draw on with JavaScript — had been supported in browsers since 2006. But it took the Flash controversy to turn Canvas from a curiosity into a platform.
The early Canvas years were rough. I built a platformer in 2011 with the Canvas 2D API. No IDE, no timeline, no animation system. You drew every frame by hand: clear, redraw every sprite, repeat. Hit testing, frame rates, asset loading — all custom implementations now. My first Canvas game ran at 18fps in Chrome and crashed Firefox when too many sprites appeared.
But the technology improved fast. Three milestones defined the transition period:
requestAnimationFrame (2011). Before this, games used setTimeout for animation loops — wildly imprecise. rAF synced rendering to the browser's paint cycle, eliminating screen tearing and cutting CPU usage on backgrounded tabs. Small API, transformative impact.
WebGL 1.0 (2011). Hardware-accelerated 3D in the browser, no plugin. Based on OpenGL ES 2.0. Suddenly you could render thousands of sprites at 60fps. The performance gap between Flash and Canvas closed almost overnight.
Web Audio API (2012). The <audio> element was built for media playback, not games. Web Audio gave us a graph-based processing system — procedural sound generation, real-time effects, sample-level mixing. Finally, a real audio engine.
By 2014, the tooling had caught up. Game engines like Phaser, PixiJS, and Three.js abstracted away the Canvas boilerplate. Construct 2 and GameMaker Studio added HTML5 export targets. The workflow started feeling productive again — not as smooth as Flash's integrated toolchain, but built on an open foundation that nobody could take away.
What We Gained (and What We Lost)
The transition from Flash to Canvas wasn't a clean upgrade. It was a trade.
We lost the Flash IDE — that seamless integration of drawing, animation, and coding in a single tool. Nothing in the HTML5 ecosystem has ever matched it. We still draw art in one program, define animations in another, and write code in a text editor. The friction is real.
We lost the sponsorship model. Flash game portals could embed your .swf and wrap it with their branding; HTML5 games live at URLs, and portals can't easily frame them without performance penalties. The economics shifted from sponsorships to ad revenue and in-game purchases, which changed what kinds of games got funded.
We lost the certainty of a single runtime. In Flash, you wrote code once and it ran identically everywhere. In HTML5, you test across Chrome, Safari, Firefox, and Edge — and each has its own Canvas implementation quirks, Web Audio bugs, and CSS rendering differences. Cross-browser testing went from optional to mandatory.
But we gained something much bigger: control. Nobody can kill Canvas. No corporation can decide to disable it on a platform. The specification belongs to the W3C and WHATWG, not to a single vendor's product roadmap. Every game I build today — every game Tom and I have built for Gerk Games — runs on technology that will outlast any company.
We gained performance. A modern Canvas game running WebGL can push more sprites, more particles, and more simultaneous effects than Flash ever could. The 60fps ceiling that felt unreachable in 2011 is now the baseline, and 120fps is achievable on modern hardware.
We gained mobile. Flash never worked on phones. HTML5 Canvas games run on every smartphone browser, no app store required. That one fact — the ability to reach billions of mobile devices without platform gatekeepers — is worth every piece of tooling we sacrificed.
Why This History Matters Now
I'm writing this in 2026, six years after Flash's official death. The browser game landscape today is almost unrecognizable from what it was in 2008 — and that's the point. It survived because the people building games refused to let the platform's death kill the medium.
Every time someone opens one of our games on a phone during a commute, or plays Snake Arena in a browser tab during a work break, they're benefiting from a decade of hard-fought technical decisions. requestAnimationFrame. WebGL. Web Audio. Canvas 2D. These aren't just API names — they're the infrastructure of an entire creative medium, built openly and maintained collectively.
Flash taught us what browser games could be. Canvas gave us the foundation to build them for real. The games we make at Gerk Games — pure JavaScript, zero dependencies, under 15KB each — are only possible because hundreds of engineers across competing browser vendors agreed on open standards rather than proprietary plugins.
That's not a technical achievement. That's an institutional one. And it's the reason I can still build games for the web — and the reason I plan to keep doing it for the next twenty years.