You're definitely right to point out that Immutable.js is really not always what you want for small values that change all the time. Immutable.js collections are best used for just that: collections. If you have to copy an array or map with a ton of entries to make a change, it's going to be super slow - Persistent Immutable data structures can help with that.
But I agree with your conclusion that any JS objects that are being used as small tuples are definitely better off staying plain JS objects.
You also don't have to use all Immutable.js or nothing at all. Similar to how using an ES6 Map collection means you don't have to stop using JS objects. Use Immutable collections where they offer benefits, but spreading it everywhere is not a performance panacea, as you rightly discovered.
You're definitely right to point out that Immutable.js is really not always what you want for small values that change all the time. Immutable.js collections are best used for just that: collections. If you have to copy an array or map with a ton of entries to make a change, it's going to be super slow - Persistent Immutable data structures can help with that.
But I agree with your conclusion that any JS objects that are being used as small tuples are definitely better off staying plain JS objects.
You also don't have to use all Immutable.js or nothing at all. Similar to how using an ES6 Map collection means you don't have to stop using JS objects. Use Immutable collections where they offer benefits, but spreading it everywhere is not a performance panacea, as you rightly discovered.