Immutable.js implements a specific set of data structures that internally share references. When you add a new field or copy an object, Immutable.js doesn't have to completely recreate things. For small objects this doesn't matter, but for _very_ large objects and arrays, it does improve performance to some extent.

With Immer and "hand-written" immutable updates, doing a `{...obj}` or `someArray.slice()` will do a "shallow" copy of the object. This is equivalent to what Immutable.js does in that it keeps all the fields pointing to the same references. However, the JS engine does have to do an O(n) processing of all the individual top-level keys, whereas Immutable.js's internal data structure is O(logN) or something like that. So, for _very_ large objects, it is faster for Immutable.js to make a copy than it is for plain JS data.

My take, however, is that

- Most apps will not be dealing with gigantic objects, so there's no perf benefit from using Immutable.js

- Immutable.js is a much larger dependency than Immer

- The fact that Immer works with POJOs _and_ gives you the ability to write trivial "mutative" syntax for updates is a huge improvement over Immutable.js's Java-inspired API

So, to me, the only hypothetical use case where Immutable.js would actually be worth it is if your app is consistently dealing with huge objects, _and_ there is truly serious overhead from copying them that needs to be optimized.