For your run of the mill website, this probably doesn’t matter. But for interactive web content, it can absolutely be a competitive advantage to use something faster and more responsive.
Like, I can feel the delay typing in a web browser compared to native, and it drives me crazy. If the output doesn't seem like a direct response to my input, I lose focus. Simple as that, and react seems to be a big part of that problem.
We have ways to go in our apps, but solid has done wonders already. Currently I'm researching state caching and optimistic updates, both of which should also improve it.
Fast enough is a myth. Instant apps are magic.
On Reddit, as another comment mentioned, yes, React seems to have been a major factor in how slow it became due to the patterns it encourages, and the massive JS sources.
You can only 'get very far' because browsers are crazy fast and you don't notice what's going on underneath. Until it catches up to you.
My general advice in such cases would be to strive for more isolation. Do use Redux. Don't be afraid to use multiple stores on one page if that allows you to isolate rerenders.
You also don't seem to understand what "rerendering" means. And that is often a problem in terms of performance. A React component only executes to determine if things have to be changed in the DOM. Not understanding this is creates a lot of pain.
Go hook up the React dev tools to Reddit and look how much each component renders. You see that components are constantly rendering even though nothing apparent has changed. I get that ideally React would only re-render when something has changed, but clearly it’s easy to create situations where react thinks something has changed even if it hasn’t.
Another good example is the Facebook website itself. It’s just so slow. I get saying Reddit developers suck, but I don’t think you can say the same about FB developers given that FB made React. React is popular because it’s a good developer experience. It’s not the best choice if you want optimal performance.
Again, connect React dev tools to Reddit yourself. Given that you’ve been given a concrete example of a slow website, I have a hard time believing you can even differentiate a performant website from a slow one.
The only performance bottleneck (I can think of) at scale with these frameworks is bundle size. Components are marginally larger in solid, and much larger in svelte. Fortunately, components don't all need to be loaded at once, and react has a lot of weight from the getgo. I cannot imagine a situation where the increased component size of svelte or solid would actually result in a larger app, even before weighing the performance gains from reactivity.
One other thing to note: An old team tried scaling with svelte once, and we ended up with react. This isn't related to performance, just DX. Solid is going much better, the primitives approach makes scale easy to reason with.
That doesn't sound right. Components are usually much smaller in Svelte, both source and compiled output; if you have hydration enabled, the JS only contains code needed to hot-patch the DOM, and not rebuild the entire template including all the static parts as react/solid does.
When Svelte still called itself the "disappearing framework", the trade-off was larger overhead in the overall project due to repeated code, but in later versions Svelte ships a runtime with a shared library.
> we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution
When we were hand-wiring components in Backbone, knockout.js etc, rendering was extremely optimized, since you decided on each and every action that would trigger it, and you did not want to overwrite potentially stateful DOM elements unless really needed.
It was way easier to get stuck into infinite loops, get desync issues, or simply completely loose track of chains of events, but unnecessary re-renders were not a major issue because they were much more expensive. React offered a solution to reason about the component tree more clearly, and along with flux and the unidirectional data flow, eliminate issues around stale data and mutations. It was not meant to be faster.
This is news to me! I switched off svelte in 2021, and onboarded with solid in early 2022. This excites me to check out svelte again
> It was not meant to be faster.
Well, this whole discussion is performance so...
Yes, if the company like reddit, facebook - which has prestige, finances and ability to hire rockstar-10x-A-players React/JS developers is unable to get their shit right and their react fronts works like garbage then it simply means that there is no hope, for some reason it's simply not possible to make performant app with React.
Especially not React itself. And even if React itself or the way it does things is "too slow" (which is the only metric that counts) then there are escape hatches or ways to deal with that.
What makes React so slow these days?
There are ways of writing React that result in vast numbers of re-renders... it's not a best practice, but it's relatively easy to make happen, especially if you ignore the official recommendations and pull Stackoverflow answers from 2015.
This alleviates all the footguns that come with rerenders (including the infamous infinite loop) and often results in cleaner code.
I'm partial to solid[0] (there are lots of comparison articles, but I think [1] and [2] show it the best). I believe svelte is similar and vue is experimenting with this as well
To steal a phrase originally about VDOM: “reactivity is pure overhead”. Nothing comes for free!
React is easy to be quickly productive in... thus, it has footguns.
You saw the same thing in the before times with Adobe Flex. So much code from people who had no understanding of the lifecycle - apps that worked but were appallingly slow and buggy.
https://emnudge.dev/blog/react-hostage
It's so easy, that we monkey patch react to debug it https://github.com/welldone-software/why-did-you-render
Plus the vdom... Isn't great, the bundle size puts react at an inherit disadvantage, and the community has a knack for over reliance on bloated packages
That would be incredibly rare. Despite the myth propagated, React is unlikely to be faster unless you were doing a ton of interleaved layout-triggering reads and writes. Even naive direct dom-diffing approaches like hyperapp/choo/morphdom can be faster.