Dogstudio / highway

Highway - A Modern Javascript Transitions Manager
https://highway.js.org/
MIT License
1.43k stars 92 forks source link

Bundle size #75

Closed mikehwagz closed 4 years ago

mikehwagz commented 4 years ago

Resolves #73, see the issue for additional context.

Replaces webpack with microbundle reducing the gzipped size of the library from 19.3kb to an average size of 2.34kb (over 87% smaller):

2.46 kB: highway.js.gz
2.19 kB: highway.js.br
2.46 kB: highway.module.js.gz
2.19 kB: highway.module.js.br
2.52 kB: highway.umd.js.gz
2.23 kB: highway.umd.js.br

In doing so, there are several considerations:

ESLint

To replace the webpack eslint configuration, I've added a lint npm script. Happy to update this. Maybe it would be worth setting it up as a precommit hook via husky since it will no longer be run automatically on build

Polyfills

Users of highway that need to maintain support for IE will need to include polyfills for fetch and Promise, plus a Map polyfill for < IE11 support. As demonstrated in #73, these polyfills can be loaded conditionally via polyfill.io by adding this script tag before highway:

<script src="https://polyfill.io/v3/polyfill.min.js?features=fetch%2CPromise%2CMap"></script>

Because Promise and Map polyfills were not required previously, this would be a breaking change and we would need to update the documentation.

Output formats

Microbundle outputs common js, module, and umd bundles out of the box. The unpkg field in the package.json file automatically resolves the umd build when loaded via unpkg. While all microbundle outputs are automatically minified via terser, perhaps it would be worth renaming the umd build to highway.min.js to ease this transition for users that are importing the minified file directly. Let me know what you think about this.

Looking forward to your feedback! 🍻

Anthodpnt commented 4 years ago

Hey @mikehwagz

That's a great work! Thanks again for the time you spent on this pull request. Everything seems good to us. May we ask you to update the documentation accordingly? You may have to change the list of supported browsers on the homepage. We believe it might make sense to keep IE11 in this list but replace the whatwg-fetch mention with a see example one that would redirect to a new example about browser support. That example would explain how to use the polyfills to support at least IE11.

For the UMD bundle name, we do agree that renaming it would make the transition easier for users. That being said, once the documentation will be updated, we'll create a new release and describe the breaking changes properly for users as well.

Best regards, Anthodpnt

mikehwagz commented 4 years ago

Thanks for the feedback @Anthodpnt. I've updated the umd bundle filename and added a new Polyfills example which is also linked in the github readme.

Just to be super thorough, I've consolidated relevant browser compatibility for each feature. Let me know if you think it might be helpful to add this table into the readme/docs somewhere!

Feature Internet Explorer Safari
Fetch API 10.1+
Promise 8+
Map 11+ 8+

Because Map is actually supported in IE11, I decided not to include it in the new example. Let me know if that makes sense to you.

Anthodpnt commented 4 years ago

Hey @mikehwagz

Indeed, I believe this might be a good idea to put this in the README. However, can you tell how this could be useful for users? It's interesting to have this table and know which feature is compatible with which browser but in the end, what's the real purpose of this table? How would it be helpful for users?

Best regards, Anthodpnt

Anthodpnt commented 4 years ago

Also, I'm going to review your PR and come back to you with a feedback as soon as I'm done. Thanks again for your motivation and your help to improve our library!