Word Ran in 1MB in 1990. Your Weather App Now Wants 1GB

You open Task Manager out of curiosity. You haven’t launched anything. RAM usage sits above 12GB. You scroll the list and there it is: the weather app, holding a few hundred megabytes hostage so it can show you that it’s 72 degrees and partly cloudy.

This complaint is a cliché by now. It has been recycled every year since Electron shipped. But in 2026 it reads differently, because one of the assumptions underneath the whole argument quietly broke. RAM stopped getting cheaper.

The Comparison That Should Not Work

Microsoft Word 1.1 shipped in 1990 on a handful of floppy disks. It needed roughly 1MB of RAM to run. That got you document editing, formatting, printing, and a spell checker.

Thirty-six years later, an app whose core job is to render one number and a cloud icon can ask for 1000 times more memory. Ask whether it does 1000 times more, and the answer gets uncomfortable. What it actually added: animated backgrounds, an ad slot, a news feed, and a browser engine to run all of it.

To be fair, modern apps carry real weight that Word 1.1 never did. They render at 4K, support the full Unicode range, negotiate TLS, and refresh location in the background. All of that costs memory. None of it justifies three orders of magnitude.

The Culprit Is Usually a WebView

A large share of desktop apps are browsers wearing a trench coat. Electron, WebView2 — either way, Chromium is running underneath. Launching one of these apps is functionally the same as opening another Chrome with a single tab.

Why build this way? The math is not subtle. Developers who know HTML and JavaScript are abundant and comparatively cheap. One codebase covers Windows, macOS, and the web. Writing native clients for each platform roughly triples your engineering headcount for the same feature set.

That’s not laziness. It’s arithmetic. The problem is where the savings land versus where the costs land: the savings show up on the vendor’s balance sheet, the costs show up in your RAM. Economists have a word for this. It’s an externality — the party creating the cost isn’t the party paying it.

For Twenty Years, Nobody Had to Care

This externality stayed invisible for a simple reason. Memory kept getting cheaper.

512MB was a luxury in the early 2000s. 8GB became table stakes in the 2010s. 16GB became standard in the 2020s. Hardware got cheap faster than software got fat, which meant any developer could end the argument with four words: RAM is cheap now.

The industry even has a joke about it. Andy and Bill’s Law: what Andy giveth, Bill taketh away. Intel makes the chip faster, Microsoft makes the software heavier, and the user ends up roughly where they started.

2026 Broke the Premise

The AI buildout inverted the memory market. Data centers are absorbing HBM and high-density DRAM at a scale that reshaped supply, and consumer RAM prices have been climbing rather than falling. It’s a big part of why laptop makers have gotten so reluctant to bump base configurations.

Change the premise and the conclusion changes with it. Every design decision made on the assumption that memory would keep getting cheaper is now running past its expiration date. Asking a person with an 8GB laptop to surrender 500MB to a weather widget is a materially different ask than it was when RAM cost half as much.

Then stack local AI on top. Running an on-device model means reserving several gigabytes in one contiguous chunk. That’s a new, hungry competitor for the same system memory. When six browser engines are idling in the background, that competition gets tight fast.

The Counterarguments Are Not Weak

The developer side of this argument deserves a hearing, because parts of it are correct.

First, Task Manager numbers lie, or at least mislead. Modern operating systems aggressively use spare RAM as cache. Much of what an app appears to hold gets reclaimed the moment something else needs it. Occupying 1GB is not the same as wasting 1GB, and the reported figure often bundles shared memory that gets counted more than once.

Second, users voted with their wallets. Given a choice between a lightweight app with fewer features and a heavy one that looks good and updates constantly, the market has consistently picked the second one. Every minimalist alternative that stayed niche is evidence for this.

Third, “just rewrite it natively” is almost always advice about somebody else’s engineering budget. For the team actually maintaining the thing, a full native rewrite may not be a real option in any planning cycle.

None of that means improvement is impossible. Teams cut memory use in half all the time without leaving the web stack — trimming dependencies, lazy-loading, killing background renderers. It’s usually not that it can’t be done. It’s that it never wins a sprint-planning argument.

The Real Question Is Who Gets the Bill

The reason this debate has run for twenty years without resolution is that it was never really a technical problem. It’s a cost allocation problem.

The vendor saves engineering hours. The user pays in RAM. And there is no price signal anywhere in the market to mediate that trade. No app store lists “this app uses 400MB of memory” next to the download button. Without information, there’s no meaningful choice — just a Task Manager that tells you after the fact.

An OS-level memory grade, surfaced per app and enforced first on the built-in apps, would change the incentive overnight. Appliance energy labels did roughly this for refrigerators. The catch is obvious: the company that would define that standard is the same company shipping the weather app.

The era of ever-cheaper memory has stalled, at least for now. The deferred bill is coming back around, and nobody in the chain looks ready to sign for it. What’s the most infuriating line item in your Task Manager right now?