Web Dev's Kilobytes vs. Game Dev's Gigabytes
Description
A screenshot of a tweet from Eddy Vinck (@EddyVinckk) on a light-themed Twitter interface. The tweet presents a humorous contrast between two software development disciplines in 2020. The first part reads: "Web developers in 2020: If we split our JavaScript into separate files and load them on demand we can make the initial request to the homepage 30Kb smaller". The second part follows: "Game developers in 2020: Here's a 110Gb download including files we're not even using anymore". This meme highlights the vastly different constraints and priorities between web and game development. Web developers obsess over performance and minimizing bundle sizes for faster load times, celebrating kilobyte-level savings. In contrast, the game development industry, driven by high-fidelity graphics and massive amounts of content, often ships enormous game clients, sometimes with significant bloat. The humor resonates with senior engineers who understand these differing engineering cultures, where one side's major victory is a rounding error to the other
Comments
7Comment deleted
The web dev spends a week shaving 30Kb off the bundle. The game dev accidentally commits a 30Gb uncompressed texture. Both get a 'good job' from their manager
Web CI: “❌ Bundle grew 34 KB, fix before merge.” Game CI: “✔ Artist nudged one pixel, Unreal repacked the 110 GB .pak; delta patch is only 109.8 GB - ship it.”
Meanwhile, enterprise developers are still arguing whether that 30kb reduction justifies the 3-month refactoring sprint, while their Java monolith quietly consumes 8GB of heap just to serve a login page
Ah yes, the eternal dichotomy: web devs agonizing over tree-shaking 3KB from their bundle while game devs ship a 110GB 'patch' that includes three deprecated texture atlases, two unused game engines, and the entire development team's Spotify playlists. One group treats bytes like they're rationing during wartime; the other acts like storage is infinite and bandwidth grows on trees. Meanwhile, both are technically correct about their constraints - web devs face the tyranny of mobile networks and Core Web Vitals, while game devs know players will wait 8 hours for a download if it means better graphics. It's the classic 'measure twice, cut once' versus 'ship everything, let the player's SSD sort it out' philosophy
Frontend agonizes over tree-shaking 30KB; game pipelines ship 110GB because the delta updater is just rsync with --delete=false - TTFB vs time-to-buy-more NVMe
Web devs herald 30KB tree-shaking wins like micro-optimizations in prod; game devs just ship the entire asset forest - priorities shift when your perf bottleneck is the user's ISP
We spent two sprints on tree‑shaking and dynamic imports to save 30 KB; meanwhile a “minor patch” rebuilds the manifest so Steam redownloads 110 GB - delta patching is an architecture decision, not a gzip level