Most apps are doing nothing most of the time

Very few applications need sustained rapid DOM changes over a long period and that’s the workload every framework benchmark is built around and almost nobody has it.

What most web apps do is sit idle about ninety nine percent of the time. Then somebody clicks a button or types in a box, and four or five things around the page need to update inside one frame which is roughly ten milliseconds once you’ve paid the browser’s own rendering overhead. That’s the actual job. It isn’t demanding and any framework written this decade can do it comfortably.

Which makes it really a shame that so many apps feel terrible anyway. They’re doing practically nothing and they still stutter, and no framework choice explains that because the thing being asked for is well within what all of them can deliver.

This is the part where React has been getting something right that gets missed in the comparisons. The work in React 18 is an attempt to work out which events matter most to the person sitting there, and to schedule the DOM changes from those interactions ahead of changes caused by everything else. When there are a lot of updates it batches them across several frames rather than trying to land them all at once.

The consequence is a bit odd. A React interface will probably be slower than one built on something leaner, measured properly with a stopwatch and it will feel faster. The changes that came from your interaction happen first and the rest arrives when it arrives and that’s what people actually want and it isn’t what a benchmark rewards.

Every framework has an upper bound on what it can push through. If you aren’t anywhere near yours then framework speed doesn’t matter at all and choosing on that basis is choosing on a number that will never bind. If you are near it, then React’s approach is the better one because it spends the available time on the part the user is paying attention to rather than spreading it evenly across work nobody asked about.

The technically faster frameworks are really faster and that’s worth something real. What it buys is headroom, and headroom is only valuable up to the point where you cross what the thing can do. Past that line the experience degrades quickly because there’s no ordering happening underneath to protect the interaction you care about.

Which matters more than it sounds, because a lot of web developers are not especially good at writing efficient code. That’s not a slight. It’s the ordinary distribution of skill in any large profession. If the framework can absorb some of that and still keep the interface quick, it’s doing something valuable that doesn’t show up in any measurement anybody publishes.

So the comparison to run isn’t which framework updates ten thousand rows fastest. It’s what happens to the one your users are looking at when your least experienced developer ships something careless into it on a Thursday.

There’s a wider habit hiding in this. Benchmarks get built around the hardest case anyone can construct, because that’s where the differences show up and a chart with no gaps in it isn’t worth publishing. Then everybody picks tools using a measurement taken at a load they’ll never see and the thing that actually decides how the app feels goes unmeasured because it’s harder to put on an axis.

Read the workload before you read the numbers.

The measurement that would actually help is one almost nobody publishes, which is how long it takes from a click to the first visible change on a page doing ordinary work on a mid-range phone over a normal connection. That number is unglamorous, it varies by app rather than by framework and it’s the only one your users are ever going to experience directly.