Your Laptop Got 1,000x Faster. Your Chat App Still Takes Three Seconds.

Your laptop is several times faster than the one you had a decade ago. Your messaging app still takes three seconds to open. Your text editor still drops half a beat between the keypress and the character appearing on screen. That contradiction is the target of an argument that keeps circulating through developer communities, and it refuses to die.

Worth flagging up front: this isn’t a hot new thread. There’s been little fresh discussion in the last 30 days. So rather than relaying live reactions, this is about why the same debate keeps landing in the same place, year after year.

What “it’s just slow, that’s how it is” actually means

Dan Luu has spent years methodically measuring software performance. His best-known work is on keyboard input latency, and the results are hard to shake off. An Apple IIe from 1983 had 30ms input latency. A 2017 MacBook running a modern web-based editor was frequently slower. CPUs got thousands of times faster over four decades, and the responsiveness a human actually feels went backwards.

The claim itself is simple: most slow software isn’t slow because the problem is hard, it’s slow because nobody looked. Optimization isn’t gated behind some elite skill set. The issues are the kind a single profiler run surfaces immediately, and then nobody does anything about them.

The low-hanging fruit is rotting on the branch

Bring up performance work and someone will quote Donald Knuth: premature optimization is the root of all evil. That line is famous mostly for being quoted with its second half amputated. What Knuth actually wrote was that we should forget about small efficiencies 97% of the time, but that we should not pass up our opportunities in that critical 3%. The back half vanishes in almost every citation.

That’s exactly where the counterargument lands. Most real-world performance problems have nothing to do with sophisticated algorithmic tuning. They look like this:

• N+1 queries hammering the database inside a loop
• Values recomputed on every render that could be computed once
• Full table scans on a column that’s missing an index
• A bundle dragging in hundreds of dependencies nobody uses

These aren’t hard problems, they’re unexamined ones. There’s code all over production that would run twice as fast after one day of profiling. Nobody ever allocates that day. That’s the actual cause.

Where would that day come from

The pushback here is real, and it has teeth.

First, performance is a metric organizations don’t reward. Ship a feature and it’s visible; it goes in the performance review. Cut app startup from 800ms to 400ms and nobody notices. Users absorb it as if it were always that way, and your manager asks what you built this quarter.

Second, most of the decisions that produced slow software were reasonable at the time. Electron apps are heavy. They also let one web team ship for macOS, Windows, and Linux simultaneously. For a company that can’t staff three native codebases, that’s a trade between performance and engineering cost, not laziness.

The same logic explains the layers. Every abstraction costs a little speed and buys back security patches, maintainability, and the ability to replace an engineer who leaves. Each individual call is defensible. Stack ten of them and the app crawls. Textbook fallacy of composition.

The AI code firehose changes the math

Reopening this debate in 2026 puts it on a different stage.

A large share of code now isn’t written line by line by a human weighing tradeoffs. An AI tool drafts it and a person reviews it. And generated code is optimized for working, not for being fast. The training data is the world’s average code, and the world’s average code is not particularly quick.

The problem is throughput. Slow code used to accumulate one line at a time, through one pair of hands. Now code of the same quality piles up dozens of times faster. The total volume of Luu’s “nobody looked” problems is growing at a rate the old debate never anticipated.

There’s a more optimistic version too. Profiling and bottleneck analysis are tedious, repetitive, and mechanical — precisely the shape of work these tools handle well. If an agent can grind through overnight what a human never got a day for, the barrier to entry for optimization collapses. But the bottleneck moves rather than disappearing: someone still has to decide to run it. That was never a tooling problem. It’s a prioritization problem, and prioritization hasn’t changed at all.

So who’s right

Honestly, each side has half of it.

Luu is right about the diagnosis. The observation that most performance problems reflect absent attention rather than technical difficulty is very hard to argue with. Consider how many production services have never had a profiler pointed at them even once.

The other side is right about the prescription. “There’s no excuse anymore” reads as a moral demand aimed at individual developers, when the cause sits in organizational incentives. At a company that doesn’t measure performance, doesn’t detect regressions, and doesn’t count improvements in reviews, individual enlightenment changes nothing.

The workable middle: treat performance as a baseline, not a feature. Set a response-time budget and break the build when it’s exceeded, the same way CI enforces test coverage. Make the system hold the line instead of relying on anyone’s willpower.

The takeaway

Do you know your product’s first-screen load time in milliseconds? If the answer doesn’t come immediately, that means nobody is watching the number.

The sharpest part of Luu’s argument isn’t “there’s no reason for software to be slow.” It’s the sentence that goes unsaid before it. We mostly aren’t failing to make software fast because we don’t know how. We aren’t doing it because we can’t find a reason to. And the faster the code piles up, the more the question becomes who supplies that reason.