Large bundle size of Terra Date Time Picker

[noahbenham]

Bug Report

Description

I just implemented terra-date-time-picker in our project and was floored to see our non-minified bundle size increase from 1.84 MB to 3.12 MB. A 1.28 MB increase of 70% that will degrade network performance loading our app and others that consume this component.

I recognize there were many OCS, UX, a11y & i18n decisions that were made while designing this component. However, I think it may be relevant to take a step back and consider alternatives to its current implementation. I'm concerned aesthetic was prioritized over performance.

The largest contributors to this inflated size are moment and moment-timezone. The general consensus seems to be that Moment is antiquated and going the way of jQuery due to its non-modular nature and better alternatives.

Steps to Reproduce

N/A

Additional Context / Screenshots

Expected Behavior

I'd expect a more reasonable bundle size increase in tens or low hundreds of kilobytes.

Possible Solution

Discussions with @benbcai indicate this could require significant effort.

1. terra-date-picker uses react-datepicker, which requires Moment. Alternatives such as react-date-picker would need to be evaluated.
   1. Evaluate locale support
   2. May need to customize to support calendar variant of terra-icon & terra-form-input
2. terra-date-picker has some utilities that use Moment to do date-time calculation/manipulations. These could be re-written natively and poly/ponyfilled for browsers without support (IE 10/11).

Environment

• Component Name and Version: N/A
• Browser Name and Version: N/A
• Node/npm Version: N/A
• Webpack Version: N/A
• Operating System and version (desktop or mobile): N/A

@ Mentions

@dkasper-was-taken @benbcai

[emilyrohrbough]

@noahbenham have you looked into these webpack optimization options? https://github.com/jmblog/how-to-optimize-momentjs-with-webpack

[noahbenham]

Thanks @emilyrohrbough, I'll look into this as a temporary solution.

[noahbenham]

ContextReplacementPlugin trimmed .16 MB from our bundle. Nothing too exciting but everything helps.

plugins: [
  new webpack.ContextReplacementPlugin(/moment[/\\]locale$/, /en/)
]

[bjankord]

We've looked at various alternatives for date pickers, the two open source solutions that matched our required feature set at the time we did the evaluation, require moment. (https://github.com/Hacker0x01/react-datepicker, https://github.com/airbnb/react-dates). While I'd like to move away from moment.js, as long as the third-party date picker we use requires it, we'll need it.

I agree that we could rewritte natively and poly/ponyfilled for browsers without support (IE 10/11) for the terra-date-picker utilities that use Moment to do date-time calculation/manipulations.

I'd recommend aliasing moment in your webpack config and measuring your production (minified) bundle. For terra-ui, we pull in all components + their example pages and the bundle size is 1019kb.

Another option would be lazyload / conditionally load the date picker / data time picker via something like https://github.com/smooth-code/loadable-components or React.lazy.

[RLRickard]

There is currently a PR open in react-datepicker that removes the usage of moment: Hacker0x01/react-datepicker#1527

[martijnrusschen]

There is currently a PR open in react-datepicker that removes the usage of moment: Hacker0x01/react-datepicker#1527

Moment.js was removed in Hacker0x01/react-datepicker/pull/1527, starting v2.0.0, this package doesn't use Moment anymore.

[bjankord]

Hearing that the third-party library we use for our date-picker has moved away from Moment.js, we may have a way to resolve this issue by updating to the latest version of https://github.com/Hacker0x01/react-datepicker.

@noahbenham you mentioned 3.12 MB was the non minified bundled size. Do you know what the minified bundled size was. I'm guessing tools like terser could shave off a lot of the size. That would give a more accurate size of what is being used in production.

[noahbenham]

@bjankord I don't have a good way of determining that since I've left Cerner for AWS. Sorry I can't help more effectively! I'd recommend reaching out to @RLRickard, Brian Bechtold or James Lawson.

[RHolland13]

About 900kb of moment-timezone's size is the tz database, which is required when running in IE, since IE's internal tz database is incomplete, which results in correctness problems for past dates. Even You Dont Need Momentjs includes the qualifier "If you are not using timezone", and admits to a lack of timezone support in alternatives. Luxon's support requires Intl (so it won't work in IE without polyfilling that), and the other options don't include support built-in, requiring adding a different library to pull in the tz database.

Note that the format moment uses to encode the tz database is specifically designed to be highly compressible with gzip, resulting in only about a 36kb increase in gzipped size over not including the database at all, according to moment's site. So if you aren't using gzip, adding it should improve things significantly, and if you already are, moment-timezone isn't actually as bad as the un-gzipped size suggests.

Additionally, depending on your usecase, you may be able to justify reducing the number of timezones included in the tz database.

Unfortunately, I'm not aware of a way to only include the tz database with moment when loading the page in IE, which would eliminate that portion of the bundle entirely when loading from modern browsers that already have a complete tz database.

[RLRickard]

When adding the change that initially included the terra-date-time-picker (along with some additional code) - our production build gzipped size went from 454 KB to 549 KB.

We have introduced some code splitting since this issue was originally logged - the chunk that includes moment-timezone and the terra-date-time-picker is roughly 52 KB gzipped and 1 MB raw. Another chunk includes terra-date-picker, react-datepicker, and moment is roughly 41 KB gzipped and 405 KB raw

[stale]

This issue has been automatically marked as inactive because it has not had recent activity. It will be closed in seven days if no further activity occurs. Thank you for your contributions.