3 ms·

I don't think 'bad performance' is a fair characterisation of Immutable.js. If you're calling .toJS() all over the place it will be doing a lot of redundant wor

I don't think 'bad performance' is a fair characterisation of Immutable.js. If you're calling .toJS() all over the place it will be doing a lot of redundant work. However there should be no need to do that, if you just pass the data structures around and access their fields directly. That's not to say that you should necessarily use Immutable.js; if you don't understand the use case where structural sharing in persistent immutable data structures is useful and require it for your application then you should probably just leave this tool on the shelf. However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects).

cel1ne 10y ago
> if you don't understand the use case where structural sharing in persistent immutable data structures is useful No need to insinuate that I don't understand. I've used it extensively in production and I think most code-bases are better off without Immutable. > However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects). It was exactly this situation, maintaining maps with thousands of GeoJSON features and working on these items, where I found Immutable to fall short. The parsing/building of the data-structure alone took, If I recall correctly, about 50 times longer than with normal JS-objects.