This has been added to the end of the post:

> Did you set shouldComponentUpdate to false? Yeah that would definitely improve matters here, unless I need to update something like a “last updated” message on a per-photo basis. It seems to then become a case of planning your components for React, which is fair enough, but then I feel like that wouldn’t be any different if you were planning for Vanilla DOM updates, either. It’s the same thing: you always need to plan for your architecture.

The Vanilla DOM equivalent is just not writing any update code until you need it. I'd argue that adding...

  shouldComponentUpdate() { return false }

...is the equivalent React way of saying "this will never be updated", but the default behaviour is the opposite of Vanilla DOM because React automatically handles updates for you, regardless of when you realised you were going to need them.

The "last updated" scenario would be a much more interesting comparison with Vanilla DOM, as a React component's lifecycle gives you an obvious place to set up/tear down the necessary timeouts on an individual basis and updates happen only when they need to. I was pleasantly surprised by how trivial it was to make _every_ time/date displayed in my Hacker News clone live-update, even down to the per-second level: https://github.com/insin/react-hn/commit/08893a046b5289b07ef...

It seems like the end result of React's diffing algorithm is going to be an appendChild. Exactly what is happening in the vanilla JavaScript. But I don't think the diffing algorithm itself is the reason for the time disparity but rather React's rebuilding of the tree to diff against the DOM. I agree with you, shouldComponentUpdate() should massively speed up React.

Because of the somewhat pathological benchmark design, he could probably implement a component for each picture and set shouldComponentUpdate to simply return false. With proper keys, I have a feeling the React performance would improve dramatically, perhaps as much or more as the pureRender mixin.