Better Documentation regarding Size and Tree-Shaking
See original GitHub issueHello!
This follows from from https://github.com/moment/luxon/issues/703 and https://github.com/moment/luxon/issues/94#issuecomment-346481639.
So, I have just moved from moment to luxon for the reasons listed on the moment homepage. When I read about using native APIs in more modern libraries or new versions of old libraries, I guess I assume that the new library will have a size savings, as well. Imagine my surprise, then, when I finally migrate everything over and find out that my vendor.js
production-built file size has increased by 170kB minified and 53kB gzipped!! (Update: the comparison I did was not apples to apples; the more accurate increase is 18kB and 4kB, respectively.)
Had I known this ahead of time, I probably would’ve stuck with moment or moved to another library like Day.js (I still might). I’m currently not using moment’s locales or its timezone addition, and at another company, I provided my own short-list of timezone data to keep moment’s size down. In a similar manner, I’m not using the bulk of what Luxon exports (ie Interval
and Zone
), but since it’s not modular I can’t tell webpack, for example, to leave certain modules out.
I’ve read discussions on things people have tried in attempt to make their file sizes smaller, but what I’d really like is a consensus on what to do for each of the popular build tools/environments, and have that be listed in the Luxon documentation page. For example, how can I point my build to use the smaller global-es6/luxon.min.js
instead of cjs-browser/luxon.min.js
that it’s currently using?
Additionally, I think it’d be really helpful to be upfront about the size costs of using Luxon (especially that you are comparing it with the fully-loaded moment library). One ideal place would be in the moment homepage under the Reasons to keep using Moment
section that discusses Luxon—knowing that library size does not actually get smaller but rather increases would be really helpful to know when comparing alternatives.
Thank you for reading!!
Issue Analytics
- State:
- Created 3 years ago
- Reactions:15
- Comments:18 (3 by maintainers)
170kb is big in 2021? How about utilizing the browser cache with versioning? I guess it is negligible.
I’ve long had on my todo list to simply experiment with this, and perhaps make changes that enhance the tree shakability of the lib. Unfortunately, I just haven’t gotten to it