Ideas to slim down the library

First of all, thanks for the great library. It worked like a charm for me.

That said, i’ve noticed that the app is bigger than I expected it to be, around 12KB after gzip. Part of the problem is that svelte has spoiled me when it comes to the size of the bundles, if this was an angular or ember library I wouldn’t bat an eye at the size.

However, it couldn’t avoid notice that my 17kb gzipped app grew to 29kb app after adding svelte-i18n and ~20 translations, which is a 70% increase.

Just listing some low hanging fruit to make the library smaller, checking if you think it’s worth to pursue them. I might help actually.

• Right now, the format store’s value is a function that has time, date, number, capital, title, upper and lower properties attached. Because of that, rollup cannot treeshake unused features. If functions for formatting dates, times and numbers were explicit exported, rollup could just remove the unused stuff (for instance, I only format messages and times, not dates nor numbers). Arguably, capital, title, upper and lower may not even belong in this library, but I can see how they are convenient.

• Maybe getClientLocale could be something users also explicitly import if they care:

import { getClientLocale, init } from 'svelte-i18n';
 init({
  fallbackLocale: "en",
  initialLocale: getClientLocale({ navigator: true }),
  ...
})

• Lastly, and this is the big one really, use intl-messageformat to compile translations during the build step. That library accounts for 4/5ths of the size of svelte-i18n. If we could compile ahead of time the translations, we could not ship the library at all. We’d have to assess if the compiled JS functions, once uglified, would be bigger than the equivalent strings using the ICU message format. I reckon that they would be slightly bigger, but probably still smaller than shipping the library unless you have thousands of translations the use plural/select or interpolations. And since we already have the functions we wouldn’t have to use memoize to cache the slow parsing process.

Are you interested in investigating any of the above? The last one fits very well with svelte’s compiler philosophy.

[cibernox]

@hmaesta I recently released a library implementing some of this ideas: https://github.com/cibernox/svelte-intl-precompile

It has an API that I think it’s almost 100% compatible with svelte-i18n. The docs say it’s for SvelteKit but it will work on any rollup-based svelte app. If shouldn’t occupy more than 2/3 kb after minification and compression.

I presented it on a lighting talk in svelte summit a few days ago: https://youtu.be/fnr9XWvjJHw?t=10004

[hmaesta]

This page has been open for 26 days in my computer as a pinned tab, just waiting for the time when I could try @cibernox’s approach. 😅

After a little struggle with Rollup, I was able to test it and save ~100 KB. 🎉

Thanks for the help. I hope it can be merged to this repository, since the name is more friendly and already have some audience.