Note that we specifically recommend _against_ using Immutable.js, and that there's many misunderstandings about the hypothetical performance benefits that Immutable.js provides:

https://redux.js.org/style-guide/style-guide#use-plain-javas...

Instead, we strongly recommend using Immer for immutable update logic, preferably as part of our new Redux Toolkit package:

https://redux.js.org/style-guide/style-guide#use-immer-for-w...

https://redux.js.org/style-guide/style-guide#use-redux-toolk...

I spent years with Immutable and discovering Immer was a game changer. Can't recommend it enough.

I didn't know about this new library but from my benchmarks it was a night and day difference moving to Immutable data structures all the way down. I understand not wanting to recommend it to newbies, but it's actually good.

If you can take a few minutes to read through https://redux.js.org/style-guide/style-guide#use-plain-javas... , and specifically the "Detailed Explanation" section there, I talked through all the perceived and actual perf benefits that you see with Immutable.js.

In short, most of the benefits people _think_ they get from Immutable.js are just properties of immutable updates in general, and there's actually some pitfalls of using it. The only real unique benefit is faster copies of _very_ large objects.

I'm not saying it's not helpful, just that it's not a silver bullet in and of itself the way some folks think it is, and that you can get similar benefits without the overhead of its API.

Immer is fantastic. It seems to be the best set of trade-offs to get as close as we can get in JavaScript to immutable reducers.