I've recently worked on back porting the "cursors" feature of Om to our React project using Facebook's immutable-js library. Although I did have some success (I

I've recently worked on back porting the "cursors" feature of Om to our React project using Facebook's immutable-js library. Although I did have some success (I got a basic POC working inside our app), the work to do a complete port of our project to this way of doing things was decided to be too much effort for the benefits it would bring. I am still, however, a big fan of the immutable/Om way of doing things with React, and it will be the way I build future React projects from the ground up. Some feedback on the article itself: "For an animation, like moving a <div> from left to right, the IRenderState function might be called several times a second. Sometimes it is better to think of your app like a movie (a cartoon, I guess) rather than a static set of objects sitting around waiting for events to happen. And if you are thinking: “that must be horribly slow”…​ well, it isn’t, thanks to React’s virtual DOM that efficiently projects changes out into the real DOM." If you're re-rendering a div in different places using Om/React in order to animate it, I would say you're probably doing it wrong. You should do one re-render to apply a new CSS transition class. Also, lots of re-rendering on desktop Chrome is, usually, quite fast because of V8 and desktop CPU's... try doing this on mobile, or (in our case) a DTV set-top-box, and you'll quickly run into performance issues. Not every JavaScript engine/platform is fast enough to pull off the naive "re-render everything" approach in React. That's why they included shouldComponentUpdate, and why David Nolen went to such effort to facilitate cheap shouldComponentUpdate checks in Om. Of course, YMMV, don't optimize prematurely, but don't also assume "re-render everything and the virtual DOM will always make it fast enough".