Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimizing for browsers #63

Closed
ephys opened this issue Oct 10, 2017 · 3 comments
Closed

Optimizing for browsers #63

ephys opened this issue Oct 10, 2017 · 3 comments

Comments

@ephys
Copy link
Contributor

ephys commented Oct 10, 2017

This is a really cool library but bundling it for usage in a browser results in a massive bundle (146KB for a bundle containing only this library, post-minification, pre-gzip).

Optimizing it wouldn't be too hard and, even while it would require a tiny bit more work on the developers that use this library I believe it would be definitely worth it.


First optimization that can be done is not loading all locales at once but only those needed by the app. There are a couple ways you can do this:

  1. By first registering the locale the app needs:
const countries = require('i18n-iso-countries');

countries.registerLocale(require('i18n-iso-countries/locales/en.json'));
countries.getNames('en'); // returns the list of names in english

countries.getNames('fr'); // throws "unknown locale, please register it first"
  1. Or the date-fns way, where the locale object is used directly:
const countries = require('i18n-iso-countries');
const en = require('i18n-iso-countries/locales/en.json');

countries.getNames(en); // returns the list of names in english

If you wish to keep the "all locales are pre-loaded" behavior on node, you can specify a different entrypoint for browsers than for node in package.json and have the node entrypoint register all locales then call the browser entrypoint.


Second optimization is getting rid of the pad dependency. The reason behind it is that this library is itself dependant on wcwidth, which itself is dependant on defaults, which itself uses clone.

That's a massive amount of code for something like pad, even more now that String.prototype.pad{Start|End} is standard and really easy to polyfill.

The best way to optimize this would be to simply use String.prototype.pad{Start|End} instead of pad, and add a note in the documentation stating that the environment needs to provide a polyfill for that function if it is not natively available. (core-js can provide these polyfills)


I can submit a PR with all this if you are interested.

Thank you :)

@michaelwittig
Copy link
Owner

PR is very welcomed. Your knowledge is way higher than mine on that topic

@ephys
Copy link
Contributor Author

ephys commented Oct 10, 2017

Perfect, I'll do it as soon as possible!

@ephys ephys mentioned this issue Oct 10, 2017
@ephys
Copy link
Contributor Author

ephys commented Oct 11, 2017

Merged :)

@ephys ephys closed this as completed Oct 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants