The world could run on older hardware if software optimization was a priority

Economic incentives vs. optimization

• Many comments frame this as a resource-allocation problem: developer time vs. hardware.
• Hardware, cloud compute, and storage are seen as “dirt cheap” compared to engineers; it’s usually rational to ship features on slower code rather than spend months optimizing.
• Several argue this creates negative externalities: e‑waste, higher energy use, constant forced upgrades, and time wasted by end‑users staring at sluggish apps. Others push back that this is just the tradeoff users and buyers implicitly choose.
• Some connect this to “enshittification” and “market for lemons”: buyers can’t easily judge software quality/performance up front, so vendors optimize for features and sales decks, not efficiency.

Bloat, UX, and real hardware

• A long thread of examples (Slack, Teams, VS Code, Outlook, web apps, Windows 11 UI, Electron generally) describe multi‑second startup times and janky interactions even on high‑end machines.
• Developers often build and test on fast Macs with fiber; typical users run mid‑range Windows laptops or old phones on slow networks, where the same apps feel painful.
• Some note that older native apps (Win9x/XP era, early Photoshop/Office, simple IDEs) felt instant on far weaker hardware; “modern” equivalents often feel slower on 100–1000× more capable machines.

Where performance went: abstractions, features, safety

• Several claim most of the 1000× raw CPU gain since ~1980 has been spent on layers of abstraction (high‑level languages, VMs, ORMs, web stacks, Electron) and richer UIs, not on bounds checks or security.
• Others counter that abstractions bought enormous developer productivity and software abundance; the marginal user often values “software exists at all” more than 2×–5× speed.
• Heated subthreads debate whether writing “fast” C++/Rust is actually that costly, or whether huge speedups (10–1000×) are often low‑hanging fruit lost to ignorance, deadlines, and cargo‑cult patterns (N+1 queries, over‑network calls, JSON‑everywhere).

Servers vs clients; I/O, energy, and scale

• Platform/infra engineers note that in large fleets, most CPU sits idle; the true bottlenecks are I/O (disks, networks, databases), contention, and bad schema/query design.
• Even small inefficiencies in widely deployed code or libraries multiply to large global energy and hardware costs, but those costs are diffuse and rarely drive product decisions.
• Others point out that in data centers newer hardware is upgraded mainly for power density and efficiency, not raw speed—older gear really can be too wasteful to keep.

Old hardware already in use

• Several remind that much of the world already runs on “old” or low‑end chips: embedded controllers, industrial systems, cars, ATMs, power plants, even space hardware with decades‑old rad‑hard CPUs.
• At home, many report perfectly usable experiences on 10–15‑year‑old desktops and laptops, provided they avoid heavy modern web apps or switch to lighter OSes and software.

Performance vs. safety and correctness

• A substantial side discussion: if dynamic bounds checking and memory‑safe languages cost ~5% performance, would that be a good trade for drastically fewer vulnerabilities and easier debugging?
• Some argue we collectively chose “1000× speed with same bugs” over “950× speed with far fewer memory issues”, and that this was a mistake; others reply that even safety competes with features, time‑to‑market, and other forms of value.

Cultural and tooling questions

• Older developers lament a lost “craft” of efficiency, replaced by “get it working” on fast machines and frameworks.
• Others note that where users or money demand speed (HFT, exchange engines, game engines, core infra, some big web properties), optimization still happens aggressively.
• There’s recurring speculation that future AI tooling might eventually help auto‑optimize bloated codebases—but also concern that current AI waves mostly amplify compute waste rather than reduce it.