The Do-Nothing Machine: How Modern Software Got Ridiculously Bloated

The cooling fan spins up.

You just opened a webpage.

A single webpage.

Not a 4K game. Not a virtual machine. Not a Chromium build. Just an ordinary page, the kind that should render some text, a couple of images, and call it a day.

Yet your browser is already devouring hundreds of megabytes. Maybe 500 MB. Maybe 800 MB. Maybe over 1 GB.

And it is still fetching resources.

JavaScript. Frameworks. Trackers. Analytics. Ads. Fonts. APIs. Another script. Yet another request. Some remote service you have never even heard of.

You just wanted to read.

Your computer decided to construct a distributed infrastructure instead.

There is something deeply wrong with this picture.

Not because modern hardware is slow. On the contrary. We possess machines vastly more powerful than those we racked in data centers decades ago. We have lightning-fast NVMe drives, multi-core CPUs, gigabytes upon gigabytes of RAM, and internet connections that make early broadband look like a joke.

And yet modern software seems stubbornly determined to waste every bit of it.

Technology moved forward.

Efficiency did not always follow.

A Request Starts Simple. Then It Turns into a Pilgrimage

Let us imagine a modern application.

You send an HTTP request.

In a reasonably simple world:

Done.

Now try mapping the path of a request in a typical modern enterprise architecture.

This is not a caricature. There are ultra-large systems where such an architecture is entirely justifiable.

The issue arises when this becomes the default everywhere.

When every application feels compelled to look ready for global social network traffic even if it serves fifty users.

When an internal CRUD tool gets deployed on Kubernetes.

When an operation that could have been a simple function call becomes an HTTP hop to another service, which pushes to a queue, which triggers a worker, which queries a cache, which hits a database.

All in the name of scalability.

The question that rarely gets asked is:

scalability for what?

Kubernetes Became a Verb

Kubernetes is a remarkable piece of engineering.

It also became an automatic reflex.

"How are we deploying this to production?"

Kubernetes.

"Do we really need dozens of containers?"

Kubernetes.

"We have three services and a database."

Kubernetes.

"This app runs fine on a single VPS."

Kubernetes.

It is as if the industry acquired a hammer so impressive that everything suddenly started looking like a nail.

And it isn't just Kubernetes.

It is the entire ecosystem.

Docker.

Helm.

Terraform.

Service meshes.

Observability platforms.

Distributed tracing.

Prometheus.

Grafana.

CI/CD pipelines.

Secrets managers.

Ingress controllers.

Autoscalers.

Operators.

Sidecars.

And dozens of other moving parts that must coordinate just to keep the lights on.

Again: none of these tools are useless.

The problem is the sum of them.

Each layer feels reasonable in isolation.

Taken together, it starts looking absurd.

Complexity Didn't Disappear. It Was Shifted

There is an implicit promise in modern abstraction layers: you no longer need to care about the details.

That holds true.

Until the day something breaks.

Then you realize somebody still has to care.

Developers don't need to know how the OS kernel schedules threads.

Platform engineers know.

Developers don't need to understand lower-level networking.

A specialized team knows.

Developers don't need to administer servers.

Great.

Now they must learn the intricacies of an internal developer platform built to abstract the infrastructure that abstracts the servers.

Complexity never disappeared.

It shifted location.

And frequently, it multiplied.

Microservices for Everything

Perhaps nothing captures this trend better than microservice fever.

The original idea makes sense.

A massive monolith can become unwieldy. Splitting responsibilities enables independent deployments, fault isolation, and selective scaling.

Perfect.

Yet there is a monumental difference between decomposing a large system and starting a brand-new project already split into fifty pieces.

When every component becomes a network service, internal calls turn into network I/O.

Network I/O turns into latency.

Latency turns into timeouts.

Timeouts turn into retries.

Retries turn into traffic spikes.

Traffic spikes turn into autoscaling.

Autoscaling turns into more containers.

More containers require more observability.

And suddenly, a call that could have been:

result = calculate()

became:

client
  ↓
API
  ↓
service A
  ↓
service B
  ↓
queue
  ↓
consumer
  ↓
service C
  ↓
cache
  ↓
database

All to perform a calculation.

It is hard to look at this without feeling something fundamental got lost along the way.

Modern Software Has an Obscene Number of Layers

Framework on top of runtime.

Runtime on top of operating system.

Operating system on top of hardware.

Application on top of framework.

Framework on top of library.

Library on top of another library.

Container on top of kernel.

Orchestrator on top of containers.

Platform on top of orchestrator.

And then someone builds an abstraction layer to hide the platform.

It is abstractions piled on top of abstractions piled on top of abstractions.

And there is one question that ought to come up far more often during architecture reviews:

"What would happen if we simply removed this?"

Not swap it.

Not upgrade it.

Not replace it.

Remove it entirely.

Perhaps the answer is "nothing".

And if the answer is "nothing", why does it exist in the first place?

Meanwhile, Your Browser Is Consuming 1 GB

Now let us step away from the backend.

Because the bloat does not stop at the server.

It reaches all the way to the end user's machine.

And the web browser might just be the grandest monument to modern bloat.

There is a historical contrast that should be impossible to ignore.

There was a time when 32 MB of RAM was enough to run an entire operating system, a full graphical desktop environment (including the X server on Linux systems), and still launch a web browser with multiple open tabs.

Thirty-two megabytes.

Today, you open a single tab and watch the browser consume hundreds of megabytes.

In some cases, well over 1 GB.

For one tab.

Not a database engine.

Not a virtual machine.

Not an application server.

One tab.

A Webpage Stopped Being a Document

The issue is that a modern webpage is rarely just a page.

It is a full application runtime.

You open it.

The browser downloads JavaScript.

JavaScript initializes the framework.

The framework constructs the application DOM.

The application fetches data.

Data arrives.

The UI renders.

Another component realizes it needs more data.

Another request fires.

Advertising scripts initialize.

Analytics scripts initialize.

Tracking pixels initialize.

Consent managers initialize.

Another third-party script joins the party.

And all of this unfolds before you can simply read the text on screen.

The web stopped being a document delivery platform.

It became a massive client-side execution environment.

At times, it feels like we put a full virtual machine inside the browser just to render a button.

Your Computer Is Now Part of the Ad-Tech Infrastructure

There is an aspect to this that is particularly grating.

A significant portion of that processing power isn't being spent to deliver what you asked for.

It is being spent to monetize you.

Programmatic advertising.

Real-time bidding auctions.

Cross-site tracking.

Analytics.

Tracking pixels.

Personalization algorithms.

Attribution modeling.

A/B testing.

Third-party scripts.

Your browser works.

The page works.

Your CPU works.

Your RAM works.

Your battery drains.

All so some remote system can determine which ad stands the highest probability of grabbing your attention.

Your computer became part of the ad-tech industry's compute infrastructure.

And you foot the bill.

With energy.

With RAM.

With CPU cycles.

With your time.

"But We Have 32 GB of RAM"

Sure.

So what?

That might be one of the most dangerous phrases in modern computing:

"There are plenty of resources left."

Just because we have 32 GB of RAM does not mean an app should consume 4 GB simply because it can.

Just because we have blazing-fast multi-core CPUs does not mean an operation that could take 10 ms should take 300 ms.

Just because we have gigabit fiber does not mean a webpage should download tens of megabytes before displaying body text.

Fast hardware does not turn waste into efficiency.

It merely masks the waste for a little while.

Until it doesn't.

Bloat Is Debt Nobody Puts on a Balance Sheet

A wasted megabyte seems trivial.

An unneeded dependency seems trivial.

An extra network call seems trivial.

One more container seems trivial.

One more microservice seems trivial.

One more third-party script seems trivial.

The problem is scale.

A thousand tiny compromises sum up to a massive system.

And because no single choice looks catastrophic on its own, nobody takes accountability for the end result.

Until the day someone opens the monitoring dashboard and realizes a straightforward application requires a fleet of servers to accomplish what should comfortably fit on a single box.

This is bloat by accumulation.

There is no single villain.

Just an endless sequence of "just one more thing".

The Cult of "Enterprise"

There is also a cultural problem at play.

Complexity looks professional.

An architecture diagram with twenty boxes looks more serious than a simple server.

An application with dozens of microservices feels more mature than a well-crafted monolith.

An infrastructure with dozens of tools feels more sophisticated than a single machine that quietly does its job.

And so simplicity starts looking like naivety.

"But that won't scale."

Maybe not.

But does it need to scale?

That is the question that should come first.

If an application serves one hundred users, there is no medal for engineering it to handle one hundred million.

There is only cost.

There is only maintenance overhead.

There is only complexity.

There is an entire on-call team waking up at 3 AM because a component nobody remembers creating decided to stop responding.

Software Should Be Fast Because It Is Good, Not Because Hardware Is Fast

Efficiency used to be a core engineering pride.

You wanted to save memory.

You wanted to minimize I/O.

You wanted to reduce latency.

You wanted to eliminate unnecessary work.

Not because hardware was pathetic.

Because waste is waste.

Today that mindset sounds almost retro.

"It works."

That phrase shuts down far too many important conversations.

It works, but it consumes 1 GB.

It works, but it requires fifteen services.

It works, but it takes three seconds to load.

It works, but it requires a constant WebSocket connection.

It works, but it drains battery life.

It works, but nobody understands how it works anymore.

It works.

And apparently that is enough.

We Don't Need to Go Back to 1998

The critique here is not an invitation to nostalgia.

We do not need to abandon modern web browsers.

We do not need to return to bare-metal servers configured by hand.

We do not need to throw Kubernetes in the trash.

We do not need to rewrite distributed systems into single-file monoliths.

We do not need to write everything in C.

The point is far simpler.

We need to recover the habit of asking whether a given layer of complexity is genuinely necessary.

Because there is a difference between a sophisticated solution and an overengineered one.

There is a difference between real scale and imaginary scale.

There is a difference between useful abstraction and ornamental abstraction.

And there is a massive difference between software that legitimately needs resources and software that wastes them because nobody cares anymore.

Perhaps the Real Breakthrough Is Removing Things

The software industry spent decades adding things.

More frameworks.

More services.

More abstractions.

More automation.

More platforms.

More tools.

More layers.

Perhaps it is time to experiment with a radical concept:

taking things away.

Fewer dependencies.

Fewer network hops.

Less JavaScript.

Fewer microservices.

Fewer abstractions.

Less infrastructure when it isn't required.

Less code executing on the user's machine for no valid reason.

Perhaps an application should simply load.

Fast.

And work.

It is an almost revolutionary idea in 2026.

In the end, the question should not be how many technologies we can stack together to build something.

It should be how many we can remove without anyone noticing.