By ByteBot
A blog post making the self-evident argument that software doesn’t need to be slow hit Hacker News this week and racked up 381 points and 272 comments in hours. The fact that this is controversial in 2026 — when hardware is a thousand times faster than it was two decades ago — is the indictment. The web’s median page ships 2.86 MB of data. The average game requires 16 GB of RAM. Windows Calculator consumes 30 MB of memory. This is not a hardware problem. This is a developer culture problem.
The Numbers: Software Performance Bloat Is Not a Feeling
The HTTP Archive Web Almanac 2025 tracks web performance across millions of sites annually. The median desktop page now weighs 2.86 MB — up 110% since 2015. Mobile pages are worse: 2.56 MB median, up 202.8% over the same period. At the 90th percentile, pages load 2 MB of JavaScript alone. Moreover, the most extreme case researchers found was a single page attempting to ship 56 MB of JavaScript.
Application bloat follows the same pattern. Games that recommended 2.7 GB of RAM in 2010 now require 16.4 GB. The Windows Task Manager — a tool that displays a list of processes — once had an 85 KB disk footprint. However, it now consumes 6 MB on disk and roughly 70 MB of RAM at runtime. Windows Calculator uses 30 MB. These are not apps doing harder things. They are doing the same things with more overhead piled on top.
The practical impact lands hardest on users developers rarely think about. For example, 100 KB of JavaScript can freeze a low-end smartphone screen for several seconds during parse and execution. The “hardware is cheap” shrug assumes your users are all on developer MacBooks. Most are not.
It Is Not a Bug. Software Performance Bloat Is an Incentive.
Developers know how to write fast software. They frequently choose not to because the incentive structures punish it. When you are choosing between shaving 200ms off a page load or shipping a new feature the product manager wants, the answer is obvious to everyone in the room — and it is not the 200ms. As Jim Mercer from IDC explains: “Commercial pressure has created a ‘velocity-over-quality’ challenge — architectural decisions get compromised by rapid feature integration demands.”
The Electron architecture is the clearest example of this calculus at scale. Building a desktop calendar in Electron means web developers can build it, it ships cross-platform, and the team avoids hiring native engineers. Consequently, five simultaneous applications on your machine now run five isolated Chromium instances consuming 500 MB to 1.5 GB each. Nobody made a bad engineering call — they made a reasonable business call. The result is a computer doing 1,000 times more work than necessary to display your meeting schedule.
AI-generated code adds a new layer to the problem. Nell Watson from IEEE notes that AI code “tends toward completeness, handling every conceivable edge case, defensive patterns everywhere” — lacking human scrutiny for efficiency. In other words, business pressure and AI defaults push in the same direction: more code, more overhead, slower software.
Related: TypeScript 7.0: The Go Compiler Delivers 10x Faster Builds
AI Just Killed the “Too Hard” Excuse for Performance Optimization
The viral piece triggering this week’s debate makes a sharp argument: AI agents have eliminated the historical barrier to performance work, which was expertise. A month-long agent-driven campaign achieved 2x–4x speedups on a regex engine. Additionally, a personal Ripgrep instance was tuned to actual usage patterns in roughly 2 minutes. In a head-to-head comparison, Claude outperformed a competent human performance engineer on a takehome optimization problem.
The argument is not that AI makes optimization trivial. Rather, the expertise gap that made optimization “expensive” is largely closed. If you have an agent that can profile, benchmark, and iterate, the remaining cost is organizational: getting buy-in, prioritizing the work, treating performance as a shipping requirement. Therefore, that is not a technical problem — it is a management problem. And management problems have different solutions.
The Performance-First Tools Are Already Winning
Meanwhile, a counter-movement is reshaping the toolchain. Rust is now standard in browser engines, operating system kernels, and cloud infrastructure. TypeScript 7.0 shipped a Go-based compiler that is 10x faster than its predecessor — a dramatic change driven by recognition that slow tooling compounds every day across thousands of engineers. Furthermore, Astro 7.2 brought a Rust compiler that cut build times by 61%. Bun migrated from Zig to Rust to reach production-grade reliability without sacrificing its performance lead over Node.js.
SQLite remains the clearest proof that the trade-off is false. A 600 KB binary powers databases on billions of devices, from smartphones to aircraft systems. It is fast because it was designed to be fast — not because hardware made the question irrelevant. In contrast, the slow-by-default camp would never ship something like SQLite, because no velocity metric rewards it.
Related: Astro 7.2: Rust Compiler Makes Builds Up to 61% Faster
Key Takeaways
- The median web page weighs 2.86 MB and has grown 110% since 2015 — not because users get more value, but because developer convenience consistently beats user experience in the incentive stack
- The “hardware is cheap” argument fails the users who matter most: those on low-end devices where 100 KB of JavaScript freezes the screen for seconds
- AI agents have largely eliminated the expertise barrier to performance optimization — the remaining blockers are organizational, not technical
- The performance-first movement (Rust, TypeScript 7.0, Astro, Bun) is gaining adoption because developers are tired of tooling that wastes their time
- Not everything needs to be SQLite — but far more software should be than currently is
Slow software is a choice. The tools to make different choices exist. The AI assistance to make optimization accessible exists. The community frustration is clearly there — 272 comments on a post about performance is not coincidental. Ultimately, the only remaining ingredient is treating performance as a first-class shipping requirement rather than an afterthought. That part, developers can fix without waiting for anyone else.
