This repository has been archived by the owner on Feb 18, 2024. It is now read-only.
Compare speed/size of babel-minify vs uglify-es #748
Assignees
Labels
Comments
|
Meant to say - in addition speed/output size considerations, we should also factor in:
|
|
Although it's looking like uglify-es's future is up in the air at the moment: |
edmorley
added a commit
that referenced
this issue
Apr 20, 2018
`uglify-js` (used by webpack 3) doesn't support ES6, so previously the web preset used `babel-minify` instead, to avoid having to transpile the generated javascript down to ES5 before minification. However webpack 4 now uses the new `uglify-es`, which does support ES6, and is much faster than `babel-minify`. As such, the web preset now defaults to `uglify-es` (which webpack 4 enables by default when `mode` is production). In addition, `babel-minify-webpack-plugin` has been found to be buggy when combined with `webpack-sources` > `1.0.1`, which required hacky workarounds in the form of yarn `resolutions` overrides and a forked version of `babel-minify-webpack-plugin`. This means we're on an old version of `webpack-sources`, which is missing fixes and performance improvements. It's likely before this PR is merged (or else before Neutrino 9 is released) that `@neutrinojs/babel-minify` will be completely detached from the web preset (and the workarounds removed) - but for now I've left it in, for easier A/B testing of the two minifiers. For more context, see: #748 It's also looking like we may want to adjust `webpack-chain` in the future, so that `optimization.minimizer` behaves like `plugins` and can have named entries for easier overriding. (To allow setting both JS and CSS minifiers there at once - especially given webpack 5 may also include a CSS minifier there too.)
edmorley
added a commit
that referenced
this issue
Apr 20, 2018
`uglify-js` (used by webpack 3) doesn't support ES6, so previously the web preset used `babel-minify` instead, to avoid having to transpile the generated javascript down to ES5 before minification. However webpack 4 now uses the new `uglify-es`, which does support ES6, and is much faster than `babel-minify`. As such, the web preset now defaults to `uglify-es` (which webpack 4 enables by default when `mode` is production). In addition, `babel-minify-webpack-plugin` has been found to be buggy when combined with `webpack-sources` > `1.0.1`, which required hacky workarounds in the form of yarn `resolutions` overrides and a forked version of `babel-minify-webpack-plugin`. This means we're on an old version of `webpack-sources`, which is missing fixes and performance improvements. It's likely before this PR is merged (or else before Neutrino 9 is released) that `@neutrinojs/babel-minify` will be completely detached from the web preset (and the workarounds removed) - but for now I've left it in, for easier A/B testing of the two minifiers. For more context, see: #748 It's also looking like we may want to adjust `webpack-chain` in the future, so that `optimization.minimizer` behaves like `plugins` and can have named entries for easier overriding. (To allow setting both JS and CSS minifiers there at once - especially given webpack 5 may also include a CSS minifier there too.)
edmorley
added a commit
that referenced
this issue
Apr 20, 2018
`uglify-js` (used by webpack 3) doesn't support ES6, so previously the web preset used `babel-minify` instead, to avoid having to transpile the generated javascript down to ES5 before minification. However webpack 4 now uses the new `uglify-es`, which does support ES6, and is much faster than `babel-minify`. As such, the web preset now defaults to `uglify-es` (which webpack 4 enables by default when `mode` is production). In addition, `babel-minify-webpack-plugin` has been found to be buggy when combined with `webpack-sources` > `1.0.1`, which required hacky workarounds in the form of yarn `resolutions` overrides and a forked version of `babel-minify-webpack-plugin`. This means we're on an old version of `webpack-sources`, which is missing fixes and performance improvements. It's likely before this PR is merged (or else before Neutrino 9 is released) that `@neutrinojs/babel-minify` will be completely detached from the web preset (and the workarounds removed) - but for now I've left it in, for easier A/B testing of the two minifiers. For more context, see: #748 It's also looking like we may want to adjust `webpack-chain` in the future, so that `optimization.minimizer` behaves like `plugins` and can have named entries for easier overriding. (To allow setting both JS and CSS minifiers there at once - especially given webpack 5 may also include a CSS minifier there too.)
edmorley
added a commit
that referenced
this issue
Apr 24, 2018
`uglify-js` (used by webpack 3) doesn't support ES6, so previously the web preset used `babel-minify` instead, to avoid having to transpile the generated javascript down to ES5 before minification. However webpack 4 now uses the new `uglify-es`, which does support ES6, and is much faster than `babel-minify`. As such, the web preset now defaults to `uglify-es` (which webpack 4 enables by default when `mode` is production). In addition, `babel-minify-webpack-plugin` has been found to be buggy when combined with `webpack-sources` > `1.0.1`, which required hacky workarounds in the form of yarn `resolutions` overrides and a forked version of `babel-minify-webpack-plugin`. This means we're on an old version of `webpack-sources`, which is missing fixes and performance improvements. It's likely before this PR is merged (or else before Neutrino 9 is released) that `@neutrinojs/babel-minify` will be completely detached from the web preset (and the workarounds removed) - but for now I've left it in, for easier A/B testing of the two minifiers. For more context, see: #748 It's also looking like we may want to adjust `webpack-chain` in the future, so that `optimization.minimizer` behaves like `plugins` and can have named entries for easier overriding. (To allow setting both JS and CSS minifiers there at once - especially given webpack 5 may also include a CSS minifier there too.)
edmorley
added a commit
that referenced
this issue
Apr 25, 2018
Notable changes: * Major version updates of `webpack`, `webpack-dev-server` and `optimize-css-assets-webpack-plugin` * Uses the new webpack 4 `mode` option * Removed `@neutrinojs/chunk` in favour of the `splitChunks` feature * Removed `@neutrinojs/babel-minify` in favour of the faster `uglify-es` * Removed redundant `ModuleConcatenationPlugin` usage * Removed default of `NODE_ENV` from `@neutrinojs/env` * Replaced `extract-text-webpack-plugin` with `mini-css-extract-plugin` * Stopped pinning `webpack-sources` to v1.0.1 * Added checks to warn about changed web preset `minify` options * Added checks to enforce that users remove any legacy `vendor` entrypoints For more details on the webpack changes, see: https://github.com/webpack/webpack/releases/tag/v4.0.0 Fixes #737. Fixes #802. Closes #748. Closes #768. Closes #769. Closes #766.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently Neutrino 8 uses babel-minify (formerly babili), in part because uglifyjs previously didn't have ES6 support.
However with webpack 4, uglify-es is now used (via uglifyjs-webpack-plugin), which supports ES6 features - plus caching and parallelisation is supported out of the box.
For projects like mozilla/treeherder, JS minification currently accounts for 80%+ of the production build time, so if there was any way to speed it up (without having a big impact on bundle size), it would make a massive difference to our end to end CI and deploy times.
As such once we're using webpack 4, we should perform another comparison of the speed/output size/features of babel-minify vs uglify-es, to see:
(a) if there are settings we could adjust to improve the speed (eg enabling parallisation with babel-minify, to match that now supported with uglify-es)
b) whether we should change the Neutrino default
c) whether we should provide a Neutrino web preset option to make it easier for uses to switch between the two
The text was updated successfully, but these errors were encountered: