Your app is not slow because of the framework

If your framework is making a real difference to how fast your app feels, you’ve probably made some horrible mistakes elsewhere.

React apps aren’t slow because of React. Vue apps aren’t slow because of Vue. Svelte apps aren’t slow because of Svelte and the pattern continues for every framework anyone has shipped. The people who build these things work very hard at not getting in your way and they do a genuinely good job of it and if your app is slow then the overwhelming likelihood is that the slow part is yours.

You can check this against what people have built. There are React apps handling tens of thousands of DOM elements at once and holding a solid sixty frames per second which is not what you’d expect if the framework carried an inherent penalty at scale. Meanwhile anyone could write a Svelte app that struggles along at five frames per second and it wouldn’t take much effort or any deliberate sabotage. Fast and slow are things you do rather than things you inherit.

There are real edge cases and they’re worth knowing about. When an app is genuinely pushing what the browser can do, framework choice starts to matter, and which one is right depends on what the app does rather than on any general ranking. If you’re updating enormous numbers of DOM elements continuously then Svelte is a good choice. If you have a lot of elements and you only touch a few of them at a time, then React or anything else built on a virtual DOM will probably serve you better.

Notice that both of those are statements about a workload. Neither is a statement that one framework is better than another and the benchmark posts that suggest otherwise are almost always measuring a workload that isn’t yours.

The awkward part is how few applications are anywhere near those edges and most web apps sit idle nearly all of the time and then change a handful of elements when somebody clicks something. If your app is a glorified to do list and an enormous number of them are, there’s no excuse for it being slow in any framework at all, and swapping the framework will not fix it because the framework was never the thing costing you the frames.

What usually costs the frames is more boring. Work happening on every render that only needed to happen once, and data fetched in a waterfall because it was easier to write that way. A list rendering every row when twenty are visible. Layout being read and written in the same tick and none of those care which framework you picked and all of them are yours to fix.

So the framework comparison is mostly a way of avoiding a harder conversation, and picking a faster one is a decision you can make in an afternoon and feel good about. Finding out which part of your own code is doing unnecessary work takes a profiler, some patience and a willingness to discover that the slow thing is something you wrote and were quite pleased with at the time.

The reason this matters beyond the argument is that framework choice gets made once, early, by whoever is around at the time, and then defended for years. If the team believes performance lives in that decision then every later slowdown becomes evidence about the framework rather than a thing to investigate and you end up with a rewrite proposal instead of a profile.

The profile is cheaper. It’s also considerably less fun to argue about at lunch which is most of why it doesn’t happen.