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

Use Google Closure Compiler instead of UglifyJS2 #4

merged 1 commit into from Oct 16, 2016


Copy link

@wildlyinaccurate wildlyinaccurate commented Oct 16, 2016

With webpack -p

Bundle size: 59K / 15K gzipped


With webpack --optimize-occurence-order and GCC

Bundle size: 41K / 13K gzipped 30% / 13% smaller


Copy link
Owner Author

@wildlyinaccurate wildlyinaccurate commented Oct 16, 2016

Comparison with be66655

Bundle size: 290K / 78K gzipped


This changeset consists of several parts.

First, in order to get the most out of GCC's advanced optimisations, I need to
make use of its ability to parse ES6 (`language_in=ECMASCRIPT6`). This means
that the es2015 Babel transformations are not only superfluous, but are
detrimental to GCC's optimiser. After trying Rollup and the
`transform-es2015-modules-commonjs` Babel transformer, I decided that was using
CommonJS was the path of least resistance.

Next, GCC's advanced optimisations rename object properties. This is especially
for this codebase not only because of the interoperation with other libraries,
but also because of the consumption of remote JSON files. To work around this,
much of the object property notation has been converted to use `obj['prop']`
rather than `obj.prop` notation.

Finally, Webpack's default minimize optimisation is disabled. Since `-p`
implies `--optimize-minimize --optimize-occurence-order`, I now run
`webpack --optimize-occurence-order` and allow the GCC Webpack plugin to
perform its own minimize optimisations.
@wildlyinaccurate wildlyinaccurate force-pushed the closure-compiler branch from ee0d68f to 964e18f Oct 16, 2016
@wildlyinaccurate wildlyinaccurate merged commit bfd8fc7 into master Oct 16, 2016
0 of 2 checks passed
0 of 2 checks passed
continuous-integration/travis-ci/pr The Travis CI build is in progress
continuous-integration/travis-ci/push The Travis CI build is in progress
@wildlyinaccurate wildlyinaccurate deleted the closure-compiler branch Oct 16, 2016
wildlyinaccurate added a commit that referenced this pull request Oct 19, 2016
Use Google Closure Compiler instead of UglifyJS2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

1 participant