[metalliqaz]

From the article:

> 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?

[wcjordan]

It is, so a DOM change wouldn't occur, but in these cases you still go through a React rendering to virtual DOM phase (templating) and the DOM tree reconciliation.

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...

[abritinthebay]

Efficient DOM manipulation is their thing.

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.

[msoad]

React won't update the DOM when render returns the same result but if you can avoid those unnecessary render calls you save some scripting time. Front-end developers have to be very conservative when it comes to running JS code. Welcome to single threaded everything programming!

[robto]

I think it is an anti-pattern that is a result of the language it's built on.

This is one place where using Clojurescript wrappers of React has a real payoff - immutable datastructures make equality checking very very cheap.

[doctorcroc]

A good patch for this is ImmutableJS