4 ms·

I would say “can cause” performance issues, but I wouldn’t say React is one of the primary reasons for poor performance. You can get very far with little optimi

by yladiz 4y ago

I would say “can cause” performance issues, but I wouldn’t say React is one of the primary reasons for poor performance. You can get very far with little optimization in React, so I am skeptical that the way React works fundamentally causes issues.

ricardobeat 4y ago
YMMV. I've been involved in multiple large-scale React projects at this point, and they all eventually suffered from performance issues, related to React's rendering model. And fixing it is always painful. 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.
- bayesian_horse 4y ago
  Then you would need to show me proof that other frameworks handle similar complexity with less performance degradation or optimize with less pain. 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.
  - rcme 4y ago
    I have experiencing on both complex React projects and complex vanilla JS projects (think the scale and complexity of Figma). Vanilla JS lends itself to being more performant. Anything that happens in Vanilla JS happens for an explicit, developer-defined reason. Things don’t rerender unless explicitly asked to. This can be both good and bad. While Vanilla JS tends to stay way more performant as complexity scales, “stale state” bugs are much more common. It’s a tradeoff.
    - bayesian_horse 4y ago
      I had the exact opposite experience. I mean, first of all, people using "VanillaJS" get the DOM manipulation wrong a lot more often. And then I do hope you don't conflate code size with complexity, because of course, direct DOM manipulation takes one heck of a lot more code (unless you create and maintain your own bespoke framework creating your own headaches). You are basically contradicting the whole reason Facebook, a pretty big and quite smart company, started React in the first place. 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.
      - satvikpendem 4y ago
        As well, people don't understand that React is an idempotent rendering framework. It's easy to reason about because of the same reason why functional languages are easy to reason about, it does not mutate but instead creates new copies.
        rcme 4y ago
        This is a discussion about perf. Creating new copies is part of what makes it slow.
        satvikpendem 4y ago
        The point is the same as functional languages, making immutable copies is what makes it easy to reason about, where reactive changes don't. There are ways to make VDOMs fast too, faster than reactive frameworks.
        bayesian_horse 4y ago
        Understanding that part means you know where to use memoization to speed up what needs to speeding up. Which isn't that much, usually.
        deleted 4y ago
  - internetter 4y ago
    Well, we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution. 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.
    - ricardobeat 4y ago
      > Components are marginally larger in solid, and much larger in svelte. 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.
      - internetter 4y ago
        > 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. 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...

by yladiz 4y ago

ricardobeat 4y ago

YMMV. I've been involved in multiple large-scale React projects at this point, and they all eventually suffered from performance issues, related to React's rendering model. And fixing it is always painful. 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.

bayesian_horse 4y ago
Then you would need to show me proof that other frameworks handle similar complexity with less performance degradation or optimize with less pain. 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.
- rcme 4y ago
  I have experiencing on both complex React projects and complex vanilla JS projects (think the scale and complexity of Figma). Vanilla JS lends itself to being more performant. Anything that happens in Vanilla JS happens for an explicit, developer-defined reason. Things don’t rerender unless explicitly asked to. This can be both good and bad. While Vanilla JS tends to stay way more performant as complexity scales, “stale state” bugs are much more common. It’s a tradeoff.
  - bayesian_horse 4y ago
    I had the exact opposite experience. I mean, first of all, people using "VanillaJS" get the DOM manipulation wrong a lot more often. And then I do hope you don't conflate code size with complexity, because of course, direct DOM manipulation takes one heck of a lot more code (unless you create and maintain your own bespoke framework creating your own headaches). You are basically contradicting the whole reason Facebook, a pretty big and quite smart company, started React in the first place. 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.
    - satvikpendem 4y ago
      As well, people don't understand that React is an idempotent rendering framework. It's easy to reason about because of the same reason why functional languages are easy to reason about, it does not mutate but instead creates new copies.
      - rcme 4y ago
        This is a discussion about perf. Creating new copies is part of what makes it slow.
        satvikpendem 4y ago
        The point is the same as functional languages, making immutable copies is what makes it easy to reason about, where reactive changes don't. There are ways to make VDOMs fast too, faster than reactive frameworks.
        bayesian_horse 4y ago
        Understanding that part means you know where to use memoization to speed up what needs to speeding up. Which isn't that much, usually.
      - deleted 4y ago
- internetter 4y ago
  Well, we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution. 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.
  - ricardobeat 4y ago
    > Components are marginally larger in solid, and much larger in svelte. 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.
    - internetter 4y ago
      > 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. 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...