Reduce prebuilt locale package sizes

[jkillian]

Wanted to port over the issue I filed at js-joda/js-joda-locale#124 to the monorepo because I think it's still relevant! The file size of the locale packages is still quite large, and in the web apps I'm building js-joda is the largest contributor to bundle size, a large part because of the locale package sizes.

(Sorry if it was annoying of me to just copy over the issue! If so, feel free to close this one, but I'd love to continue discussion at least!)

Original comment:

First off, js-joda is great! It makes me actually happy when working with dates/times in TypeScript. So thanks for the work!

However, I recently noticed that our @js-joda/locale_en-us package we're using is quite large. It's one module, as of version 2.0.1, is 302KB which unfortunately bloats our bundle quite a lot. (Of course this filesize will get smaller when uglified and gzipped, but it still adds up to be quite a lot)

In our use case, all we want to be able to do is parse/output a few simple things like month abbreviations and 'am'/'pm'.

I admit I don't fully understand how these packages are built or what's in them. Do you have any recommendations for reducing bundle size in this case? Thanks!

[jkillian]

Response from phueper:

Hi @jkillian ,

thanks for using js-joda and reporting the issue.

The problem is that for the js-joda-locale package we need to implement parsing and formatting not only for month abbreviations but for all available patterns. We depend on data from cldr that provide some packaging of available localisation strings. There are strings in these packages that we do not need but the packages are as they are.

So i'm afraid at the moment i don't know how to help you reduce the bundle size ... we could think about providing something like "core" packages that only contain some localisation functionality in the future but that is not on the roadmap currently :/

I'll close the issue because of this, feel free to reopen/ comment if you feel there is some way to address this.

Regards, Pattrick

[jkillian]

My response:

Thanks for the response @phueper! Just a couple notes below I wrote up when I was looking at things:

I was first curious about is how much of each locale is actual logic related to parsing and how much is data. When looking at node_modules/@js-joda/locale_en-us/dist/index.js, it's about 300KB, about half of that, 150KB, is data and the other half is logic/code.

As a (somewhat unfair comparison, but a comparison nonetheless), the data for a moment locale appears to be about 4KB.

In the js-joda locale, it looks like the biggest consumers of space are:

cldr-data/supplemental/metaZones.json: 72KB
cldr-data/supplemental/likelySubtags.json: 38KB
cldr-data/main/en/timeZoneNames.json: 32 KB

@phueper I'm curious how this data overlaps with js-joda-timezone? Is there anyway to eliminate the timezone data from the locales packages and instead rely on the timezone data from js-joda-timezone? This could be significant space savings for users.

Another question I have is what the use of cldr-data/supplemental/likelySubtags.json is? Eliminating this would also be significant space savings.

And then these are the remaining data files:

cldr-data/supplemental/weekData.json: 4KB . (so not too bad, but seems to contain data for all locales)
cldr-data/main/en/ca-gregorian.json: 7KB (seems like most of this data is relevant)
cldr-data/availableLocales.json: 3KB (seems like it contains all locales, but this is relatively small so not too bad)

Any thoughts on the above comments? I'm mostly just trying to get a grasp here of what it causing the size bloat and on what data is truly necessary vs. what is extraneous. It seems like time timezone data here is what's the biggest offender.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[daniel-nagy]

I was really excited when I discovered js-joda. However, bundle size is the reason I will not use js-joda in a Web application. For anyone curious here is the generated en-us local package. Examining that file, it looks to me like most of that information is unnecessary. According to bundlephobia this is 43kB gzip, making your total investment in js-joda close to 100kB gzip if you only use the en-us locale.

I also think calling the core package lightweight at 43kB gzip is misleading. I would not consider that lightweight for a dependency of a Web application. I do think 43kB is competitive for a date library if that included localization.

For comparison Luxon is just over 20kB gzip and uses existing browser APIs for localization. I'm not saying Luxon is better than js-joda, quite the contrary, but when it comes to putting things on the internet size still matters.

[psigns]

This is major a pain point for our team as well. @pithu are there any plans to address this in the near future? It looks like the main milestones on the public roadmap have been reached since the original issue was opened.

[pithu]

Very likely its a new issue caused by moment/moment-timezone#999

Feel free to open a new issue, but unfortunately i have limited capacity to work on it