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.htm...
No better article than this: https://blog.vjeux.com/2013/javascript/react-performance.htm...
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?
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.
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
> and IMO not even cases where the "organizational" benefits of such libraries are salient
Apparently, that is what it ultimately boils down to:
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.
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.
> 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)
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.