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

Every game on Gerk Games is a single HTML file. No bundler, no framework, no transpiler. And no, that's not laziness. It's a deliberate bet on simplicity. Here's why.

The Framework Tax

A minimal React setup adds ~40KB before writing a single line of game code. Vue adds ~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 JS with Canvas gives us total control. Our average game file is 8KB. Total. All logic, rendering, sound, touch support. On a 3G connection, that's a 2-second load instead of 8-10 seconds with a framework.

Bundle Size Comparison

For a simple HTML5 game like Snake Arena (approximately 800 lines of game logic), using Webpack adds roughly 40KB to the bundle size — the Webpack runtime and module wrapper overhead. Vanilla JS ships the same 800 lines as approximately 4KB of minified code. The 10x size difference has a measurable impact on first-load performance: on a 4G connection, the Webpack version takes approximately 2 seconds to load versus 0.3 seconds for vanilla.

Development Workflow Costs

The tradeoff for choosing vanilla JS over Webpack is developer productivity. Webpack provides hot module replacement, automatic bundling, tree shaking, and a vast ecosystem of loaders and plugins. Without these tools, the developer must manually manage script loading order and concatenate files. For a solo developer building games with small codebases (under 2000 lines), the manual workflow is manageable and the performance benefit is worth the productivity loss.

When Webpack Makes Sense

For game projects exceeding 5000 lines of code, or projects with multiple developers, or projects that depend on large third-party libraries, Webpack's tooling benefits outweigh its size penalty. The breakpoint is roughly around the 50KB script size — below 50KB, the Webpack overhead is proportionally large. Each game on Gerk Games stays under 50KB of minified JS, which is why we consistently choose vanilla JS over build tools.

Practical Implications for Site Performance

The choice between Webpack and vanilla JS has a measurable impact on site-wide performance metrics. Each game page on Gerk Games loads a single HTML file with inlined CSS and JS. Total page weight averages 25KB. A Webpack-bundled equivalent would average 65KB per page. On a site with 45 game pages, the total bandwidth savings of the vanilla approach approaches 1.8MB per full site visit. For mobile users on limited data plans, this difference can determine whether they browse multiple games or leave after the first one.

Developer Experience: Real Tradeoffs

The developer experience tradeoff between Webpack and vanilla JS extends beyond build tools and bundle sizes. Vanilla JS development requires manually managing script loading order, which becomes painful as the codebase grows beyond 2000 lines. Webpack handles dependency resolution automatically, catching missing imports at build time rather than runtime. For a team of multiple developers, Webpack's module system prevents the common error of one developer referencing a variable defined in another file that has not been loaded yet. The decision ultimately comes down to team size and codebase complexity. For solo developers building self-contained games under 2000 lines, vanilla JS is the right choice. For teams building complex applications over 10,000 lines, Webpack's tooling benefits are worth the bundle size cost.

Real-World Metrics from Gerk Games

Across all 45 game pages on Gerk Games, the average HTML file size (with inlined CSS and JS) is 24KB. Equivalent pages built with Webpack would average 62KB. The total bandwidth savings across a user session that visits 5 game pages is approximately 190KB — not a massive number for a single user, but significant when multiplied across 10,000 daily visitors. At scale, this bandwidth savings translates to roughly 570GB per month in reduced CDN egress, which is a real cost saving for an independent site operating on a tight budget. Beyond cost, the faster load times directly improve user retention metrics by reducing the abandonment rate during page transitions between games.

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.