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?
(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.
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:
> 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.
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.
One project I worked on was a BI tool with a fair amount of complex state. Before we introduced react we were using backbone, event listeners, and managing dom state ourselves. With react we made it declarative, which simplified things.
Another project was an email client with a lot of complex state and caching. That started with and continued to use react so I don’t have a direct performance comparison. But again, managing the state manual would have been a nightmare.
Thanks in particular for the second example: it's a precise idea which can be studied (the former still is too abstract).
> managing the state manually would have been a nightmare
Now, of course, the annoying follow-up question would be "why?". For sure, there are poor ways to handle complex states without React, but that doesn't mean it's impossible to do it fairly well either.
For example, a divide and conquer strategy might make the situation less miserable already: associate "components" (DOM nodes) to relevant portions of the state only. But it's still too difficult to get a clear idea without actual code (hence my original question: most of the discussions about this are either objectively too hypothetical because they deal with complex/private codebases, or unconvincing toys)
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.
No better article than this: https://blog.vjeux.com/2013/javascript/react-performance.htm...