[tim333]

>2 We could throw out the entire list and rebuild it in one go, but re-rendering large amounts of DOM is also slow.

Out of curiosity I tried swapping "<ul><li>Artichokes</li><li>Broccoli</li><li>Cabbage</li><li>Dill</li><li>Eggplant</li></ul>"

and the same without the broccoli and dill, back and forth a few thousand times using jquery.

The average time per change was 28 nanoseconds or 35000 changes per second (Chrome, MacBook Air). Trying swapping a list of 300 fruits for a list of 500 fruits was 1.4 milliseconds per change.

I wonder if using some convoluted framework to "solve—or at least mitigate" this might be premature optimisation? (As well as actually slower).

[peeja]

Author here. I actually glossed over some of the problems here, as the article was already getting quite long. In a trivial example like this, you're right. If you do this to the entire page, though, it gets stickier. An additional problem is that you're throwing away and rebuilding state that's associated with the elements, such as event handlers. (Also, letting React do the actual DOM manipulation makes it easier to implement transitions, where a Virtual DOM element goes away now, but the real DOM element sticks around for a bit while it animates off.)

To be fair, I haven't done actual benchmarks, and I'm basing this on the stated rationale for React. I'd be surprised if swapping out the DOM of most of the page wasn't considerably slower more difficult to work with than what React does, though.