[i_s]

> I want to stress this once more – for an average app you can skip React or other virtual DOM at start and only go for it once it gets too slow (or never).

I don't think this is good advice. It would be better to just start by using something like React, then if things get too slow, implement shouldComponentUpdate, because you will almost certainly need something that can make efficient DOM updates instead of just naively recreating whole DOM trees.

[Suor]

Using framework has its cost, so you can be better of if you understand clearly what you are doing. OTOH, framework brings structure so it's less probable you skrew up your design.

[acjohnson55]

I think your piece does a great job of highlighting the design principles behind React and friends, but in reality, I see nothing wrong with having your cake and eating it too: understand the principles but still use a battle-tested framework with a strong community around it. I don't see why everyone should reinvent the same abstractions. Your last sentence really nails it.

Great piece though. It's good for programmers to understand how powerful the concept can be of factoring state out of actions of your app.

[baddox]

shouldComponentUpdate is nontrivial to implement when you're using mutable application state. I feel like all React tutorials should at least mention this, but sadly most seem to say something like "do not worry about performance until it becomes a problem, then just implement shouldComponentUpdate."

[i_s]

If you have a slow react component that uses mutable data structures for state, and implementing shouldComponentUpdate is hairy, you could always switch to using immutable data structures for that component's state instead. That change alone is very easy. From there, implementing shouldComponentUpdate is very straightforward.