[amelius]

I think the main problem with your argument is that you assume that the world looks like a shallow tree. For UIs this may be, to a great extent, true. But for non-frontend code, the world looks more like a deep DAG (directed acyclic graph).

Also, suppose I have a list of thousands of elements. Now suppose one element is added to the list. React will still perform a comparison operation on all of those thousands of elements.

[simplify]

> suppose I have a list of thousands of elements

That's going to be a problem regardless. You shouldn't have so many elements on one page (can a user even parse through so many at once?). Use pagination or occlusion culling to show a few at a time instead.

[dangoor]

Premature optimization is the root of all evil. Using immutable objects means that the overhead for checking a component that has not changed what it's rendering is a couple of function calls plus an object identity check. Modern JS can do that very, very fast.

And, if you find that it's still too slow, there are other strategies you can employ to fix it without having to turn your whole application into a stateful soup. Odds are, though, that this is not going to be your bottleneck.

[pramodliv1]

>> React will still perform a comparison operation on all of those thousands of elements.

Using the `shouldComponentUpdate` API alleviates the problem, doesn't it? https://facebook.github.io/react/docs/component-specs.html#u...

[epmatsw]

Eh, kind of. If you're rendering, for example, a Table with a lot of TableRows and change one of the values in the data array being passed to Table.props, you'd return true from Table.shouldComponentUpdate, and then each child TableRow would need to run its shouldComponentUpdate, even though only a single one really needs to update. So the argument is GP is making is that it's more efficient to directly update that single DOM element rather than update the data and then perform the calculations to determine that we need to update that single DOM element.

[bryanlarsen]

True in theory, but as long as each TableRow implements the PureRenderMixin and the Table render itself is efficient, you're going to need a lot more than a thousand rows before React has any trouble hitting 60fps in my experience.

But if you can't meet both those conditions, that sort of thing definitely can get quite slow.

[matchu]

Are modern CPUs really going to choke on a few thousand comparisons?

My impression has always been that, for any constant-time operation, you're gonna need to start getting into the 100Ks or even the millions to start noticing, but I don't have the data to back me up here :/