Why We Don't Use Webpack, React, or Any Framework for Browser Games

Every game on Gerk Games is a single HTML file. No Webpack, no React, no Vue, no bundler, no transpiler. This isn't laziness — it's intentional. Here's why.

The Framework Tax

A minimal React setup adds roughly 40KB of JavaScript before you write a single line of game code. Vue adds about 30KB. A bundled Webpack project adds build complexity, config files, and dependencies that need updating. For a game site where every KB affects load time on slow mobile connections, this tax is unacceptable.

Vanilla JavaScript with Canvas gives us full control over performance. Our average game file is 8KB — total. The entire game, including all logic, rendering, sound, and touch support. On a 3G connection, that's a 2-second load instead of 8-10 seconds with a framework.

The Developer Experience Fallacy

The main argument for frameworks is developer productivity. With React, you can build UI components faster. With Webpack, you can use CSS modules and hot reloading. These benefits are real for web applications. They are irrelevant for browser games. A browser game is not a web application. It is a real-time rendering engine with a game loop. The mental model of components and state management is fundamentally different from the mental model of canvas coordinates and frame timing.

I have built the same game in React and in vanilla JavaScript. The React version took 3 hours longer to code (because of the overhead of creating components for the tile, the score board, the menu, etc.) and ran 30 percent slower (because of React's reconciliation cycle on every state update). The vanilla version took less time to write and ran faster. There is no scenario where a framework improves game development for a self-contained browser game.

The real cost of frameworks is something developers rarely calculate: maintenance burden. A game built with Create React App in 2022 requires dependency updates by 2024 (React 18 had breaking changes). A game built with vanilla JavaScript in 2010 still runs in a browser today. I can open Snake Arena's original source code from 3 years ago and it works immediately. I cannot say the same about any React project I have touched.

The Dependency Tax

Every framework and build tool you adopt is a long-term tax, not a one-time convenience. A React-and-Webpack setup means a node_modules folder with hundreds of packages, each of which can break, each of which needs security updates, and any of which can be abandoned by its maintainer. For a small game that is fundamentally a canvas and a loop, that machinery is wildly disproportionate to the problem. We write vanilla JavaScript because the dependency tax for our games is simply not worth paying — there is nothing a framework would do for a self-contained arcade game that plain code does not do more durably.

The Game Still Works in Five Years

A vanilla JavaScript game written today will run unchanged in a browser five years from now, because the browser platform is committed to backward compatibility. A game built on this year's framework versions may not even build five years from now without a painful migration through several breaking releases. For a catalog of games we want to keep online indefinitely with minimal maintenance, longevity beats developer convenience every time. The most maintainable code is the code that depends on nothing that can rot.

When a Framework Is Actually Right

To be fair, frameworks exist for good reasons. A large application with complex shared state, many developers, and constant feature churn benefits enormously from the structure React provides. Our point is not that frameworks are bad — it is that they solve problems our small, self-contained games do not have. Choosing tools should follow from the actual shape of the problem, and the honest shape of a 13KB arcade game does not call for a build pipeline.