A real build step for a faster load
For a long time Warbirds shipped its browser code exactly as written — two dozen source files and a full copy of the 3D library, sent raw. That's changed. There's now a proper build step that strips out everything the game doesn't use and squeezes the rest, so the client downloads a fraction of what it did before. Same game, less to fetch.
What was happening before
The whole game runs in your browser — the flight model, the rendering, the networking, all of it. That code lived in a couple dozen separate files, plus a big general-purpose 3D library, and the server just handed them over as-is. It worked, but it meant sending a lot of bytes the game never touches: whole corners of the 3D library we don't call, comments, whitespace, long readable variable names — all downloaded on your first visit for no benefit.
What the build step does
Now the code goes through a bundler first. Three things happen to it. Tree-shaking walks the code and throws away anything nothing actually references — the unused two-thirds of the 3D library simply doesn't ship. Minifying rewrites what's left into the same logic in far fewer characters. And bundling stitches the pieces into a small handful of files instead of two dozen round-trips.
The upshot: the 3D library alone dropped by roughly two-thirds, and the game's own code came down by a similar margin. Once your browser has cached it, the shared 3D chunk carries across page loads, so bouncing between the game, the leaderboard, and this dev log doesn't re-fetch it. The result is a quicker first load, especially on a phone or a slow connection.
Groundwork for three separate theaters
The other reason to do this now is deployment. Warbirds runs as three theaters — the air war, the naval war on the ocean map, and the land war on the steppe. Today they're one program that picks a theater when it starts, and one client that decides which to draw once it knows where it's connected.
A build step is the thing that eventually lets those three come apart: a naval-only change can rebuild and redeploy just the naval server while the air and land instances keep running untouched. That full split is still ahead — this change lays the pipeline it stands on and wires each server image to build its own client. You won't see any of it from the cockpit, which is the point. It just loads faster.