Wouldn't this break immutable.fromJS?

Thanks for opening this. I agree we want to eventually get here.

Some subtasks:

• Deprecate all methods like toMap() in favor of passing instances to Map() constructors.
• Ensure common methods which return full structures are factored out (groupBy() is a good example) into helper functions instead.
• Find a new build path which allows for a single distribution file independent of node style requires.
• Investigate bytesize addition of Browserify and Webpack in partial-build mode.

@pluma it won't break it no. But of course, if you require "immutable/fromJS" then you'll implicitly also be requiring Map and List.

👍 here. I love this library but 56kb is a tough pill to swallow.

It's only 15kb if you serve the min file and your host uses gzip (they all do)

I'll note that's 1/10th the size of most JPEGs on your site

Oh I certainly didn't mean it as a petty attack, I apologize if I came across that way.

In the grand scheme of things, 15kb is nothing compared to the value you get out of this library. But I did to express my interest in exploring ways to reduce this weight. It just feels like there's an easy win here.

No worries, no harm. I just want to make sure the number is clear, and it's in perspective.

I just also want to caution looking at this task as a source a big win. In it's current form, this isn't going to do much for you, but what this task does do is allow for the library to expand and include new data structures without impacting byte size. That's going to be important as I plan to add SortedSet/Map and more useful structures in the future.

Currently the bulk of the library is distributed across three files: Iterable, Map, and List. List and Map both extend from Iterable, so at the very most you could drop from 15kb to 10-12kb if your application uses only Maps or only Lists. I also haven't evaluated how much weight using Webpack or Browserify would add to the size for partial builds vs the ultra-thin Esperanto packager currently used for full builds, my hypothesis is somewhere around 0.5-1kb, but this is something I'll investigate.

+1

+1!

I would love a modular approach as well, now that immutable v3 comes with so much goodness built-in it's overwhelming sometimes (just to go through doc and remember those API).

Or maybe a immutable-core module offering low level API? There is a https://github.com/mattbierner/hamt but unfortunately didn't get expanded upon. https://github.com/rtfeldman/seamless-immutable is much closer to native data structure but doesn't use hamt underneath.

Still, many thx to your hard work.

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

Deprecate all methods like toMap() in favor of passing instances to Map() constructors.

I would just like to point out some issues around getting rid of toMap(). Take a look at #600 and #697. Ideally, this sort of behavior would fit better under the map() function, but you cannot specify keys via map() currently.

RxJS has great structure that allows to add operators and typings to prototype at runtime (e.g. add/map and map).

But as @leebyron said in #1044 (comment)

However I don't actually think you would shave much from the ~15kb build already. That's roughly split into thirds: Map, List, and everything else.

It would be overkill for current implementation. To make profit from it - we totally should add another dozen of methods to operate on collections

Also from #1044 (comment)

Specifically right now all types have a toList() and toMap() etc methods which convert between various collection types. That ties all of the library together and tree shaking typically isn't smart enough to trim prototype methods as well.

This can be solved with babel-plugin e.g. babel-plugin-lodash, babel-plugin-material-ui.

I know my team uses just fromJS, merge, mergeIn, set, get, setIn, getIn. That's basically it.

Perhaps groups of prototype methods could be added on demand. So I'm going from the naming in the docs here, these groups could be optionally loaded:

• transient changes
• sequence algorithms
• combination
• creating subsets
• reducing a value

The other method groups would probably not be optional, but don't seem necessary for a "lite" version of immutablejs.

Also curious you say it's just Map and List, but there is also OrderedMap, Set, OrderedSet, Stack, Range, Repeat, Record, Seq. Those data types should also be optional.

Yeah we also use basically fromJS, merge, mergeIn, set, get, setIn, getIn.

Looking forward to this.

I will note the main issue is not with the actually size of immutable, its just when you add all the other deps in a normal project they really add up. 20-30% off each library adds up to allot

👍

I'm going to close this issue since we now export an ES module as well, which tools like webpack and rollup will use when bundling to achieve tree shaking.

We should still attempt to deprecate methods like toMap() which make tree shaking more difficult, but the bulk of this work has been done by improvements to tools in the ecosystem over the last few years!