Why We Build Browser Games With No Frameworks

This site runs seven games and exactly zero JavaScript dependencies. There is no React, no game engine, no bundler, no transpiler, no package.json in production — every page is plain HTML that loads plain CSS and one or two hand-written script files. In 2026 that is an eccentric position, so this essay is our attempt to defend it with numbers rather than nostalgia: what the constraint actually buys us, what it genuinely costs, and the small set of habits that make framework-free development pleasant instead of masochistic.

The numbers, since we promised numbers

All game logic on GameHanpan totals roughly 74 KB of unminified JavaScript. The smallest game, Emoji Memory Match, is 4.9 KB; the largest, Bloom Blocks, is 21.4 KB with its two modes, touch gestures and animations. Snake is 7 KB. Space Canyon — a full physics flyer with procedural level generation — is 17.4 KB. Our shared bilingual i18n runtime, written from scratch, is 5.7 KB. For comparison, a typical React + ReactDOM bundle alone is about 140 KB minified before a single line of game code: our entire seven-game catalog costs half of an empty framework. On a phone over mobile data, the practical result is that the time from tapping a link to actually playing is about two seconds, most of which is the network, not the code.

Reason one: speed is a feature players feel

Mini games live in stolen moments — a coffee break, a bus stop, the void between meetings. In that context, every second of loading is a percentage of the play session. A framework-free page has almost nothing to parse and nothing to hydrate, so it is interactive nearly as fast as it renders, even on the aging office PCs and low-end Androids that real audiences actually use. Our games hold 60 fps on modest hardware not because we are heroic optimizers but because there is simply not much code standing between the game loop and the canvas.

Reason two: longevity without a treadmill

Anyone who has maintained a JavaScript project knows the dependency treadmill: security advisories for packages you forgot you had, breaking major versions, build tools that stop building after an OS update. Vanilla JavaScript is the only layer of the stack with a decades-long compatibility promise — browsers still faithfully run code written in the 1990s. We expect these pages to work, unmodified, in ten years. There is no lockfile to rot, no framework migration in our future, and when we open a game's source next year it will still be exactly the code we wrote, top to bottom.

Reason three: privacy as an architecture, not a policy

Framework-free also means we know precisely every network request our pages make, because we wrote all of them. Game state and best scores live in your browser's localStorage and are never transmitted anywhere; there is no analytics script, no tracking pixel, no session recorder. The only third-party code on the site is the ad script that pays the hosting bill, clearly visible in the page source. "View source" on any of our games shows you the actual, readable program — which we consider both a privacy statement and a small act of respect for the curious twelve-year-olds who learn programming exactly that way, as some of us once did.

How we stay sane without a framework

The honest secret is discipline borrowed from the framework world and applied by hand. Every game is an isolated IIFE module with no globals except one deliberate export. Wherever possible we split the pure logic from the DOM: Snake's collision rules and 2048-style board math are plain functions that also run in Node, which means a command-line test script exercises them without a browser — merge logic, spawn behavior, edge cases — before anything touches a canvas. Our i18n system is a 170-line script that swaps text via data attributes; it does one job and has needed essentially no maintenance since it was written. None of this is clever. It is the boring 20% of framework ideas that deliver 80% of the value, minus the 140 KB entry fee.

What do we give up? Real things: component reuse across pages is manual copy-and-adapt, there are no compile-time types catching our mistakes, and if this site had login, feeds and collaborative state, hand-rolled DOM updates would collapse under the complexity. We would reach for a framework without embarrassment the day the problem demanded one. That is the actual position — not that frameworks are bad, but that a 4×4 puzzle grid does not need a virtual DOM, and pretending otherwise costs our visitors bandwidth, battery and waiting time to solve a problem we do not have.

The test that keeps us honest

Our benchmark is unglamorous: open any game on a mid-range phone, on mobile data, and count the seconds until you are playing. Try it now with Memory Match or Snake — and while it loads (briefly), remember that everything you just downloaded fits comfortably inside a single photograph. If browsing the source teaches one person how a game loop works, the whole policy has paid for itself. Questions about how any of it is built are welcome on the contact page.