Performance does matter to the people who depend on our products. Can we please stop throwing people under the bus in the name of churning out more crap?
The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much. The fact that React can prioritize rendering of some things over others means that it can be slower overall, but still feel faster to users.
> The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much.
I don't know, IME it's pretty easy to run into bottlenecks with React. To resolve these, you have to spend time optimizing data flow and preventing unnecessary re-renders, and it can be really difficult to trace where an update originally comes from. Svelte and other reactive frameworks give you good performance by default, so it's very unlikely you ever have to do this in the first place.
I never had to deal with `useMemo` and `useCallback` equivalents in Vue apps. The framework is implemented in such a way that it can let me focus on the task at hand. If I have errors in Vue apps, they are logic errors not "you didn't cater to the framework's rendering model" errors
What is the actual difference between React and Svelte? People don't actually know, but this isn't like the old days where React offered 10x (or more) performance increase over AngularJS without even trying to optimize. We're arguing "better" using very slim margins.
Looking at the geomean benchmark suite everyone uses, it's 1.33 for Svelte 4 and 1.67 for React. That's a mere 0.2x difference and most of that is due to row swapping performance from React iterating lists of thousands of elements -- hardly typical in most apps.
Your team will make THOUSANDS of decisions in your app that will make WAY more difference than 20%. Incorrectly nest some loops in your data processors and the performance difference will almost instantly outshine the update differences.
And all of this is without mentioning that the React team is working on a compiler that will offer many of the benefits you get from the custom Svelte compiler (though TBH, I dislike needing a special compiler for custom JS).
EDIT: I'd also add that the Stage 2 record/tuple proposal will make comparing props many times cheaper and should give a massive performance boost to React as this comparison is one of the things that slows it down.
The statistical performance difference is somewhat irrelevant. The measure should really be the extra time spent optimizing your code, and that value can be far higher in React than it is in Svelte. It doesn't matter if the raw performance difference is only 20%—if that 20% means the difference between a smooth UX and a janky experience, it's still extra work you have to do with React that you don't need with Svelte.
Now, I'll grant you that it really depends on the project. Building a simple admin interface? This probably won't matter. But for an interactive dashboard with dynamic charts and data being updated in realtime? You're almost certainly going to spend some time making it fast. And optimizing React code is currently a pretty poor experience.
For the record, I'm not arguing that the performance difference alone makes Svelte worth using over React. In fact, I think the developer experience with Svelte is far better, which is (in the majority of cases) a much better reason to use a framework. I just want to dispel this myth that React is so fast that you'll likely never have to think about performance, because I've had to do a non-trivial amount of optimization work on just about every React codebase I've worked on.
Performance does matter to the people who depend on our products. Can we please stop throwing people under the bus in the name of churning out more crap?