I would recommend immer (https://github.com/mweststrate/immer) instead of ImmutableJS. You can work with regular JS objects, plus it plays much nicer with TypeScript.

I wrote a tiny library called fn-update for this that does composable functional updates (https://github.com/benvan/fn-update).

Personally, I prefer not having to mutate data, even wrapped in a produce method

Having to specify the path using an array of strings would be an instant dealbreaker for me. It messes with all tooling and is bad for readability.

I suppose immutable.js supports partial reuse of objects, that is, if you only change the value of one attribute, the changed copy has this attribute set differently, but the rest is shallow-copied?

If so, indeed immutable objects would not run into the problem of copying, as long as you can afford them to be immutable. (That is, you're not working with any APIs that assume and use mutability.)

ImmutableJS is a pretty huge library. I'd conjecture most web apps don't have a legitimate need for something so comprehensive and would be better off with a simpler solution.

If you know the shapes of your objects ahead of time you can create one-off functions, which will probably be faster and require far less code.

I cannot recommend ramda enough. It provides the immutability and flexibility of immutablejs, but because it's build in a functional paradigm, the logic is fully composeable so complex, deeply nested changes are very simple and readable.

That is an apples to oranges comparison. ramda does not provide persistent data structures.

both are used to approach the same problem: immutable manipulation of javascript data. The fact that immutableJS provides a persistent object is an implementation detail in the strategy used to solve that problem.