I avoid using immutable because it is a huge chunk of code relative to my apps, and for initial page load on mobile, every KB matters. I do get it via third party components, which I then load on-demand only.

However, I noticed that the size is always the same, 57KB minified (using the excellent webpack-bundle-analyzer), which is also the size that it ships with in the npm package.

I doubt that all third party modules use all functionality, so that means that the minification cannot identify unused pieces of code. I build with webpack tree shaking, which works using ES2016 export syntax, first identifying unused exports, not exporting them, and then letting the minification remove any unused code.

So, I think that the immutable library could be smaller if it was also available in an es flavor (in the same package, via a package.json key) that exports everything separately.

However, that will only help if the code is "chunky", so that if you only use e.g. a Map, it will only touch part of the code.

Furthermore, the code should not have side effects. I noticed a lot of createClass calls, the minifier won't be able to optimize those away because it cannot assume it to have no side effects.

Another caveat is that lodash faces the same problem, and the lodash-es build is not helping, probably due to the fact that the default export exports everything as an object. Lodash has to resort to a Babel plugin that rewrites import {foo} from 'lodash' to import foo from 'lodash/foo', and as a consequence, both lodash and lodash-es get the same build size without tree shaking.

TL;DR: If Immutable is "chunky", it can lead to smaller build sizes by tree shaking iif it has an es build and it doesn't export everything on default and things like createClass are done at build time. I think/hope.