Why I Make Browser Games
Someone asked me recently why I make browser games instead of publishing on Steam, or itch.io, or building a mobile app. The question surprised me because to me the answer is obvious, but when I tried to articulate it I realized it was less obvious than I thought. So here's my attempt at an answer.
The frictionless thing
A browser game has a property that no other distribution platform has: zero friction. Not low friction — zero. You send someone a link. They click it. They're playing. No app store, no install prompt, no account creation, no loading screen with a progress bar that stops at 97%. The game is just there, immediately, in a tab they already know how to use.
This sounds trivial until you watch someone try to share a mobile game with a family member. "It's on the App Store, search for..." The moment the friction appears, half the potential players are gone. With a browser game, you put the link in a WhatsApp message and that's it. The barrier is one tap.
I think about this frictionlessness a lot because I make games for people who are not gamers. My parents, for instance. My parents will never install an app to play a game I made. But they will click a link. That matters to me.
The constraint is the point
I have a rule: no dependencies, no build tools, no bundlers. The game must work as a single HTML file (or a small handful of files). No npm, no webpack, no TypeScript compiler, no deployment pipeline. Open the file. Done.
People sometimes hear this and think it's a limitation I'm tolerating. It's the opposite — it's a creative choice I actively want. Constraints force clarity. When you can't reach for a library, you write simpler code. When there's no build step, there's nothing to configure or break. When the whole thing fits in one file, you can actually hold it in your head.
The best code I've ever written has been under the most constraints.
Easter Hop's particle system is about 40 lines. The physics engine is six constants and three lines of math per step. I'm genuinely proud of how small these systems are, in a way I'm not proud of much larger codebases I've worked on professionally. Small, complete, understood — that's the feeling I'm going for.
Making something finished
Most side projects don't get finished. They get started, reach maybe 30% completion, and then get abandoned when something else demands attention. I've been guilty of this for most of my adult life — there's a graveyard of unfinished things on various hard drives.
Browser games are the format where I actually finish things. The scope is naturally bounded. You don't need a level editor, a tutorial system, a save system with cloud sync, a settings menu, an accessibility audit. You need the core loop to be fun and the basic experience to work. You can ship something complete in a weekend.
That feeling of completing something — a thing that works, a thing someone else can use right now, a thing that didn't exist three days ago — is what keeps me coming back. It's not about audience size or revenue. It's about the finished-thing feeling. I don't get that from work projects very often. I get it from these.
The web is still good
There's a school of thought that says the open web is dying — walled gardens, app stores, platform lock-in, everything moving toward native apps or locked-down ecosystems. I find this view genuinely sad, and I also think it's somewhat wrong. The web is still there. HTML still works. Canvas still renders at 60fps. A page I put on GitHub Pages today will be accessible to anyone with a browser for the foreseeable future, with no platform owner able to remove it, delist it, or change the revenue terms.
Making browser games is, in a small way, a vote for that version of the internet. One where you can put a thing on a URL and anyone can reach it. It's not going to change anything at scale. But I'd rather spend my hobby time building for the open web than for a platform that can pull the rug whenever it wants.
That's why I make browser games. Small, finished, frictionless, free, and mine.