Why we ship vanilla JavaScript instead of a game engine

About twice a week, someone emails or messages to ask why the games on this site are written in plain HTML and JavaScript instead of using a real engine like Phaser, PixiJS, or Unity's WebGL exporter. It's a fair question. I want to answer it honestly, because the answer isn't "frameworks are bad" — it's more interesting than that.

1. The page is the product

The first reason is the one most engine builders underrate. When a player clicks a link to a Phaser game, they wait for the page to load, then they wait for the Phaser runtime (usually 200–600 KB) to download, then they wait for the game's own bundle. Best case: two seconds. Common case: five. On mobile data: more. That's a long time to ask a kid to wait for a game they didn't even know they wanted to play.

When you click on, say, Wurdle on this site, the page is fully rendered in under a second on most connections. The HTML is twelve KB. The game's JavaScript is another fifteen. There is no engine. There is no library to download. The whole thing is faster than the splash screen on most native games.

For a casual browser game that someone is going to play for two to ten minutes, that load time is the entire user experience. If we can't get them to a playable state in under a second, we've lost.

2. Vanilla JS is excellent at small games

The HTML5 Canvas API is honestly pretty pleasant to work with once you know it. ctx.fillRect, ctx.arc, requestAnimationFrame, a couple of event listeners. That's most of what you need. For a game like Flappy Rocket or Frog Hopper, the engine you'd need to build yourself is maybe two hundred lines. An engine is overkill.

Where engines start to pay off is around the point where you have: thousands of simultaneous sprites, a scene graph with parent-child transforms, asset preloading, physics with collision detection between dozens of bodies, networked multiplayer. None of our games need any of that. Tower Defender probably has the most simultaneous entities (lasers, enemies, effects) and it never exceeds a few hundred. A canvas can handle a few hundred draws per frame on a phone from 2015. You don't need WebGL for that.

3. The kids can read the code

This is the reason that matters most to me personally. My teenager can open the source of any game on this site and understand what's happening, because there is no abstraction in the way. When she wants to change how the wheel spins in Ultimate Decision Wheel, she opens one file, finds the function called spinWheel, and changes the easing curve. She's not learning a framework. She's learning JavaScript. That skill follows her everywhere.

When the time comes for her to use React or Phaser professionally, she'll have to learn the framework's conventions, but the underlying mental model of "a function changes a variable, the canvas redraws on the next frame" will already be solid. That's the long game.

The good argument against me

The honest counterargument is: I'm spending engineering time on problems someone else has already solved. Every time I write a tween from scratch, every time I implement a sprite sheet animator from scratch, every time I roll my own input system, I'm doing work that a framework would do for free. That work adds up. Over a year I've probably re-implemented the same animation queue four times.

For a single developer or a small team building one game, an engine is almost certainly the right call. For a site like this one — many small games, fast load times, kids learning the platform — vanilla is the right call. The answer depends on what you're optimising for. We're optimising for time-to-play and learnability of the source. We get both.

If you want to see what twenty-something games written this way actually look like, the whole catalogue is on the home page. Click any of them. Notice how fast the page is.

— Chris