4 ms·

I would give up Immutable because of it's bad performance and often confusing api. Also I'd give up Mocha, Chai & Sinon for tape, which is way simpler and more

by cel1ne 10y ago

I would give up Immutable because of it's bad performance and often confusing api. Also I'd give up Mocha, Chai & Sinon for tape, which is way simpler and more than enough: https://medium.com/javascript-scene/why-i-use-tape-instead-of-mocha-so-should-you-6aa105d8eaf4#.53b5r8pfe https://medium.com/javascript-scene/why-i-use-tape-instead-o...

flanbiscuit 10y ago
haven't tried out Tape but if I could get rid of 2 libs and just use one then that's great.
vmasto 10y ago
Care to provide sources for Immutable's bad performance?
- acemarke 10y ago
  There is some overhead to its use, both conceptually and with actual performance. I wrote a comment a while back describing some concerns with using it [0]. I also have some links relating to potential performance issues as part of my React/Redux links list [1]. [0]: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4/?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1]: https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master...
BigJono 10y ago
Gulp is obviously not needed as well. That's the most confusing dependency in this stack imo.
mambodog 10y ago
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.

by cel1ne 10y ago

flanbiscuit 10y ago

haven't tried out Tape but if I could get rid of 2 libs and just use one then that's great.

vmasto 10y ago

Care to provide sources for Immutable's bad performance?

acemarke 10y ago
There is some overhead to its use, both conceptually and with actual performance. I wrote a comment a while back describing some concerns with using it [0]. I also have some links relating to potential performance issues as part of my React/Redux links list [1]. [0]: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4/?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1]: https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master...

BigJono 10y ago

Gulp is obviously not needed as well. That's the most confusing dependency in this stack imo.

mambodog 10y ago

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.