I wrote a long Reddit comment a while back that describes the reasons why I advise that people _not_ use Immutable.js [0]. As a quick summary: - It doesn't ma

I wrote a long Reddit comment a while back that describes the reasons why I advise that people _not_ use Immutable.js [0]. As a quick summary: - It doesn't magically improve perf the way some people think it will. It does make easier to use the standard shallow equality implementation of `shouldComponentUpdate`, and can be faster at copying/updating very large objects. However, many people use `toJS()` to extract values, and that is absolutely bad for perf (especially if you call it in `mapState`). - You either have to use its API everywhere in your codebase, or spend a lot of time encapsulating it to keep your components unaware of its existence. - It can be harder to debug the contents of the objects. I'm not sure about specific downsides for using Seamless-Immutable. My React/Redux links list has a section of articles that discuss the pros and cons of using Immutable.js for performance [1]. I've also got a section on use of immutable data in general [2], including some articles that talk about how to actually use Immutable.js in your app, and articles on using plain JS data immutably. [0] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4/?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md https://github.com/markerikson/react-redux-links/blob/master...