First, from a technical perspective, a well-designed React app should only evaluate the minimal parts of the tree that have changed. And React can do that easily with the PureRender mixin, or you can do it manually with the componentShouldUpdate method.
Secondly, from an empirical perspective, one of React's major selling points is that it renders many classes of DOM-based apps (and others) much more quickly than previous methods (e.g. jQuery, Angular) could achieve. React reduces the overall time spent performing CPU-intensive tasks, even if there is (_if_) there is an increase in CPU-time spent book-keeping.
Of course, it would be moot if the DOM wasn't so utterly dreadful from a performance perspective. But apparently it is fundamentally broken or it would have been fixed years ago.
Making a simple local change to a list of N items, which would normally take O(1) energy, suddenly takes O(N) energy. Even with the PureRender and componentShouldUpdate methods, because React will traverse the complete list to determine which items should be changed (calling componentShouldUpdate for every item).
I agree with you on the DOM. Its speed needs to improve. React offers a nice abstraction which may keep the code simple, but, as explained here, has problems of its own.
In an ideal system, Components receive props, modify internal state, and render idempotently based on these. The PureRender mixin is a way of saying "yes, this component conforms to the above constraints".
Unfortunately, it's not always the case that the naive way of writing a Component will comply with the PureRender restrictions, so it's not enabled by default. It's not difficult, 99% of the time, to alter a Component to work properly with only minimal changes, and they aren't changes that make the Component code more confusing.
ComponentShouldUpdate is a way of applying tree-trimming logic that React could not automatically know. Business logic and the like. When a Component implements componentShouldUpdate and returns false, it will prevent any children of that component being iterated in that loop. Ideally, componentShouldUpdate should just returning a Boolean value from state, rather than calculating it each time.
Yes, but when you alter 1 element of a list L, then L must be iterated (simply because it changed), so componentShouldUpdate() will return true for L. As a consequence, all elements of L will be checked. But you only changed one!
If you change the elements in a set, you need to re-evaluate how that set is rendered. Wether you leave it to the elements to decide if they are to be altered, or have that logic in the set-handling code, the book-keeping (and related CPU time) still needs to occur?
Either way, the proof is in the pudding: React is so insanely faster for this specific case than all other approaches.
Certainly the Virtual DOM is one way to let you declaratively write to the DOM and not worry about change tracking yourself. But it's not the most efficient way.
This is the ideal way you should be writing your React components anyway; I can't think of any edge cases where you don't want this (I'm sure they exist though)!
I feel that this is scaremongering without real hard data. I'm happy to be proved wrong, should React be shown to be slower than an app that is updating the DOM with big blocks of innerHTML then reattaching event handlers, for example.
With something like Redux and React you can connect only the parts of your tree that will change and react won't re-compare the whole tree as I understand it.
It is rare to have an expensive shouldComponentUpdate that returns true most of the time, but there is definitely a trade-off there that depends on the specifics of how data flows through your app. People like to put it on everything but we (React team) believe that it's probably best to put it in a few well-intentioned places. This tension is something we're actively thinking about.
Generally React is 'very fast' to 'fast enough'. A very admirable situation to find yourselves in :-)