> Fixing the issue is pretty simple*. We simply need to short circuit the re-rendering for a subtree if we know that the subtree hasn’t changed.
Not a frontend guy but I've seen this theme more than once on HN recently. It seems to me that addressing this anti-pattern would be built right in to modern React components. Isn't efficient DOM manipulation by pruning non-necessary changes kind of their thing?
Since these can be slow (although much faster than a DOM change), it makes sense to check and skip those steps when you can.
The focus of most of this article is how you can skip those steps when you're components input data is unchanged and common gotchas related to that.
Some other great posts in this vein are: https://facebook.github.io/react/docs/optimizing-performance... and http://benchling.engineering/performance-engineering-with-re...
But that sentence is talking about VirtualDOM rendering - which still takes time - not DOM manipulation.
Basically it's saying "if we don't need to do work, we shouldn't". Which React already does for DOM manipulation and this kind of optimization does it for virtualDOM creation.
This is one place where using Clojurescript wrappers of React has a real payoff - immutable datastructures make equality checking very very cheap.