[asolove]

(Edit: posted this comment before I read the article, doh.)

These is certainly something wrong with the benchmark. Since Om is a layer on top of React, it is obvious that React itself cannot be necessarily slower than Om. (Perhaps idiomatic React usage is slower than idiomatic Om usage for this case, though?)

[matchu]

See the article's discussion of immutability in Elm. Om has the same immutability property, so configures React to take advantage of that property, skipping vanilla React's property diffing.

edit: Rather, see masklinn's comment that describes what actually happens. Point being, vanilla React does extra work to account for anything a developer might do, but allows Elm and Om, which have more rigorous standards for their users, to override that behavior.

[masklinn]

Vanilla React doesn't do property diffing by default, it re-renders the whole tree then diffs the whole virtual DOM, because it can't rely on data immutability or on components purity.

Since Om or Elm assume immutable inputs and pure components they can skip rendering components altogether when the inputs have not changed (mentioned in TFA's "Making Virtual DOM Fast").

React can do that, but it has to be opted in component by component either by using PureRenderMixin or by implementing shouldComponentUpdate.

[matchu]

Gotcha—I'd assumed property diffing was the way to go because it hadn't occurred to me that folks would be writing impure components. Thanks!