Back to Opinion Articles
Opinion #006•5 min read•13 August 2026

The Internet Is Getting Faster. Software Is Getting Heavier.

We keep building faster networks, better hardware, and larger cloud infrastructure — yet the software running on top of all of it keeps demanding more, and the reason says more about engineering incentives than about technology itself.

Rajnish Kumar

Rajnish Kumar

Editor-in-Chief & Founder

The Internet Is Getting Faster. Software Is Getting Heavier. — Opinion article hero image
Editor's Note

Written to question a quiet trade-off in modern software: as infrastructure gets faster and more abundant, software keeps getting heavier. This piece asks whether we've started treating abundant computing resources as permission to stop caring about efficiency — and where the line lies between useful complexity and unnecessary waste.

The Question Nobody's Answering

By almost any measure that mattered in 2010, computing infrastructure in 2026 should feel close to instant. Fixed broadband speeds have climbed dramatically, while fiber and 5G have made high-bandwidth connections increasingly ordinary. s have replaced spinning disks across most mainstream consumer devices, dramatically reducing storage latency. Cloud providers deliver more compute per dollar every year, not less. And yet the software running on top of all of it doesn't feel proportionally faster — for a lot of people, it feels slower than it did five years ago. That gap is the actual subject here: if everything underneath our software keeps getting faster, why does software itself keep getting heavier?

Everything Underneath Really Did Get Better

This isn't a nostalgia complaint dressed up as a trend piece — the infrastructure gains are real, large, and well documented. Over roughly the last decade: None of this is in dispute. The infrastructure side of computing has kept its half of the bargain.

  • Fixed-line and mobile connections have grown far faster and far more consistent, thanks to fiber build-outs and 5G rollouts
  • CPUs now deliver dramatically more compute per chip than the processors that powered servers fifteen years ago
  • SSD and NVMe storage cut read/write latency by an order of magnitude over mechanical drives
  • The cost of compute and storage has generally fallen over time, while the amount of infrastructure available on demand has exploded

Yet Software Kept Getting Heavier

But software didn't simply use those gains to become proportionally faster or more efficient. HTTP Archive's 2025 Web Almanac puts the median home page at 2.86 MB on desktop and 2.56 MB on mobile — up 110% on desktop and 203% on mobile over the past decade alone. Desktop apps tell a similar story: Discord's desktop client has been documented climbing from under 1 GB of RAM during normal use to as much as 4 GB. Electron-based applications such as Slack, Microsoft Teams, and Visual Studio Code package Chromium and Node.js as part of their runtime, trading resource efficiency for cross-platform development speed and consistency.

The Hidden Trade-Off

None of this happened by accident, and none of it happened because developers got worse at their jobs. It happened because abundant resources changed what optimization is for. When RAM was measured in megabytes and a network round-trip was genuinely expensive, every byte had to justify itself — there was no other option. When RAM is measured in gigabytes and bandwidth is nearly free, that constraint disappears, and with it goes the pressure that used to force lean design. The trade-off is real: abundant resources bought developers speed of delivery. What they cost, quietly, was the discipline that scarcity used to enforce for free.

"Hardware Is Cheap" Became an Excuse

That trade-off has a name. Wirth's Law — coined after computer scientist Niklaus Wirth's 1995 essay "A Plea for Lean Software" — holds that software gets slower faster than hardware gets faster. The example that made it stick: despite the processing gains predicted by Moore's Law, Microsoft Office 2007 performed the same task at half the speed on a contemporary 2007 machine that Office 2000 managed on a 2000-era machine. "Hardware is cheap, add more RAM" stopped being a stopgap and became a design philosophy — one where bandwidth, memory, and CPU cycles are treated as a substitute for optimization rather than a budget to respect.

AI Makes the Problem More Interesting, Not Simpler

AI complicates this story instead of simplifying it, because both halves of the paradox are true at once. Real AI workloads are genuinely, legitimately compute-heavy — Gartner projects worldwide data center power demand to grow 26% in 2026 alone, driven largely by AI-optimized infrastructure, with total data center electricity consumption on track to roughly double by 2030. That weight is earned; running a large model is not the same problem as rendering a chat window. But "AI everywhere" as a product strategy is a different thing entirely — a chatbot widget bolted onto a settings page, a model call where a lookup table would do, a background inference job nobody asked for. One is compute spent on capability. The other is compute spent on a feature list.

The User Pays the Final Price

Every layer of unnecessary weight eventually lands on someone who didn't choose it. It shows up as a laptop fan spinning up to render a webpage, a phone battery that drains faster with every update, a storage warning on a device that hasn't changed how it's used in two years. Apple's battery-management controversy showed how software decisions can materially affect how users experience the remaining life of their hardware — a case that made explicit what had always been true implicitly: decisions made far away from the user determine how long their device feels usable.

“Infrastructure got faster so software could do more with the same budget. Instead, software mostly used the extra room to stop budgeting at all.”

Is Heavier Software Always Bad?

Not automatically, and it's worth resisting the urge to romanticize the lean software of the past. Abstraction layers, richer interfaces, and yes, some AI features genuinely make software more capable and more usable for more people — a framework that costs a few hundred extra kilobytes but cuts a team's shipping time in half, or an editor that renders complex documents instantly because it isn't hand-rolling every pixel, is heavier and better at the same time. The honest version of this argument isn't "small is virtuous" — it's that weight has to be earned by what it delivers.

The Real Problem Isn't Size — It's Waste

That's the distinction most of this debate skips past. The real failure isn't that software got bigger — it's that it got bigger without anyone deciding it should. Slack's own 2019 desktop rebuild is proof the alternative is available whenever a team actually prioritizes it: moving to modern JavaScript tooling and a rebuilt architecture got the app launching 33% faster, using 50% less memory, and connecting to calls up to ten times quicker — with no loss of functionality. That wasn't a stripped-down version of Slack. It was the same product, built with the assumption that resources still had a budget.

What Good Engineering Should Mean Now

Good engineering in 2026 isn't about refusing every dependency or chasing kilobyte counts for their own sake — that's a different kind of waste. It's about treating "we have the RAM for it" as a starting point for a decision, not the end of one. Every framework, every bundled runtime, every AI call should be answering a question — what does this actually buy the user — rather than coasting on the fact that nobody will immediately notice the cost. Capability without unnecessary consumption isn't a slogan; it's just optimization done with today's constraints instead of 2005's, applied on purpose instead of by default.

The Cost of Confusing Abundance With Permission

Faster infrastructure was supposed to give developers room to build better software, not a reason to stop asking whether a byte, a dependency, or a model call earns its place. The paradox in the title isn't really a paradox once you see the mechanism behind it — it's what happens when abundance gets mistaken for permission. Technology gave us more resources. Good engineering should still decide how little of it we actually need to waste.

Sources

The data points and claims above are traceable to the reporting and reports below, linked here rather than woven inline so the argument stays readable and the numbers stay checkable.

Found this useful? Share it