4 ms·

People forget what problem the virtual dom and react is supposed to solve. No better article than this: https://blog.vjeux.com/2013/javascript/react-performanc

by ibash 2y ago

People forget what problem the virtual dom and react is supposed to solve. No better article than this: https://blog.vjeux.com/2013/javascript/react-performance.html https://blog.vjeux.com/2013/javascript/react-performance.htm...

Spivak 2y ago
And then Svelte showed that you could avoid all that with a compilation step and live update the dom efficiently. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead React is also at the point where re-rendering the whole app is a fiction the library maintains for you while being smarter and doing less, why not go the whole way?
- ibash 2y ago
  Agree, react is way too bloated right now. The original idea and first versions were great.
  - culi 2y ago
    The original idea and first versions were extremely inefficient and unscalable
- Aeolun 2y ago
  And then SolidJS showed that you could do the same thing even without a compilation step.
guax 2y ago
For me is because is hard to remember that problem while dealing the the ones react brings.
insane_dreamer 2y ago
There are plenty of cases where optimizing for performance isn't necessary. This is where React is not worth the extra headache and complexity.
- presentation 2y ago
  React is set to become much less complex as a user once the react compiler is in place and if you use server components/actions; in my product we’ve already basically eliminated 95% of useEffect calls, almost all data fetching, client side state management with the current gen tools, and once the compiler is in then all memoization will be gone too. You still end up with the bloated bundle size but with one of the more modern react alternatives you can eliminate that too. So at least for me, I don’t mind the build complexity for the power I get; especially now that node itself is supporting typescript, the build side is getting simpler to set up as well.
mbivert 2y ago
(honest question, not trying to be snarky) Do you have one (many would be great) use cases where the practical gain of the virtual DOM solutions have a genuine impact? I'm asking because, many of React (or friends) introductory material naturally focus on building things like TODO lists or Tic Tac Toe; while those offer insights into how to work with React (& cie), they're not showcasing cases where the performance gains are perceptible, and IMO not even cases where the "organizational" benefits of such libraries are salient.
- eterps 2y ago
  This question is crucial to understanding the true value of React and virtual DOM technologies. While there's no doubt that React and virtual DOM offer advantages, it's essential to clearly demonstrate where and how these benefits manifest in real-world applications. > they're not showcasing cases where the performance gains are perceptible According to this commenter, it's not even about the performance gains: https://news.ycombinator.com/item?id=41271272 https://news.ycombinator.com/item?id=41271272 > and IMO not even cases where the "organizational" benefits of such libraries are salient Apparently, that is what it ultimately boils down to: https://news.ycombinator.com/item?id=41271367 https://news.ycombinator.com/item?id=41271367
  - mbivert 2y ago
    > While there's no doubt that React and virtual DOM offer advantages, it's essential to clearly demonstrate where and how these benefits manifest in real-world applications. Definitely; it's a struggle to find precise, concrete arguments in this direction. And there are many good reasons to be conservative: e.g. inheritance-based OO was sold with "VW inherits Car"; looks great on paper, but not as much in front of real-world issues. > Apparently, that is what it ultimately boils down to: If so, I'd be left wondering how much of this is actually caused by a lack of discipline, as seems to be for example indicated by the "dumb reflows" issues.
- NohatCoder 2y ago
  Obviously this always depends on what code you compare it to. I don't think there can be much doubt that a well written performance oriented framework-free implementation is in practice always going to be faster than anything using virtual DOM, as one can update simply the parts that need updating without creating the virtual DOM in the first place. If you assume programmers who don't know what they are doing it is a very different question. Some people will manage to make a train wreck both with and without a framework. But if we assume that there is a skill level where people will manage to make something useful with a framework, but not without it, or vice versa, then I really do not know which way it swings.

by ibash 2y ago

Spivak 2y ago

And then Svelte showed that you could avoid all that with a compilation step and live update the dom efficiently. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead React is also at the point where re-rendering the whole app is a fiction the library maintains for you while being smarter and doing less, why not go the whole way?

ibash 2y ago
Agree, react is way too bloated right now. The original idea and first versions were great.
- culi 2y ago
  The original idea and first versions were extremely inefficient and unscalable
Aeolun 2y ago
And then SolidJS showed that you could do the same thing even without a compilation step.

guax 2y ago

For me is because is hard to remember that problem while dealing the the ones react brings.

insane_dreamer 2y ago

There are plenty of cases where optimizing for performance isn't necessary. This is where React is not worth the extra headache and complexity.

presentation 2y ago
React is set to become much less complex as a user once the react compiler is in place and if you use server components/actions; in my product we’ve already basically eliminated 95% of useEffect calls, almost all data fetching, client side state management with the current gen tools, and once the compiler is in then all memoization will be gone too. You still end up with the bloated bundle size but with one of the more modern react alternatives you can eliminate that too. So at least for me, I don’t mind the build complexity for the power I get; especially now that node itself is supporting typescript, the build side is getting simpler to set up as well.

mbivert 2y ago

(honest question, not trying to be snarky) Do you have one (many would be great) use cases where the practical gain of the virtual DOM solutions have a genuine impact? I'm asking because, many of React (or friends) introductory material naturally focus on building things like TODO lists or Tic Tac Toe; while those offer insights into how to work with React (& cie), they're not showcasing cases where the performance gains are perceptible, and IMO not even cases where the "organizational" benefits of such libraries are salient.

eterps 2y ago
This question is crucial to understanding the true value of React and virtual DOM technologies. While there's no doubt that React and virtual DOM offer advantages, it's essential to clearly demonstrate where and how these benefits manifest in real-world applications. > they're not showcasing cases where the performance gains are perceptible According to this commenter, it's not even about the performance gains: https://news.ycombinator.com/item?id=41271272 https://news.ycombinator.com/item?id=41271272 > and IMO not even cases where the "organizational" benefits of such libraries are salient Apparently, that is what it ultimately boils down to: https://news.ycombinator.com/item?id=41271367 https://news.ycombinator.com/item?id=41271367
- mbivert 2y ago
  > While there's no doubt that React and virtual DOM offer advantages, it's essential to clearly demonstrate where and how these benefits manifest in real-world applications. Definitely; it's a struggle to find precise, concrete arguments in this direction. And there are many good reasons to be conservative: e.g. inheritance-based OO was sold with "VW inherits Car"; looks great on paper, but not as much in front of real-world issues. > Apparently, that is what it ultimately boils down to: If so, I'd be left wondering how much of this is actually caused by a lack of discipline, as seems to be for example indicated by the "dumb reflows" issues.
NohatCoder 2y ago
Obviously this always depends on what code you compare it to. I don't think there can be much doubt that a well written performance oriented framework-free implementation is in practice always going to be faster than anything using virtual DOM, as one can update simply the parts that need updating without creating the virtual DOM in the first place. If you assume programmers who don't know what they are doing it is a very different question. Some people will manage to make a train wreck both with and without a framework. But if we assume that there is a skill level where people will manage to make something useful with a framework, but not without it, or vice versa, then I really do not know which way it swings.