Babili (babel-minify)

We released Babili as beta (0.0.1) a few days ago under an MIT license!

Try it out in the Babel REPL and report any bugs or potential optimizations we can make! There’s also a #minify slack room!

There are a lot of (valid) questions about why a new minifier is a good idea, so this post should help with that.

TL;DR: Babili can accept ES2015+ input, while current minifiers are mostly limited to ES5, requiring code to be transpiled before minification. This is becoming unncessary as people begin to ship ES2015 to clients. Babili is also modular/flexible (being a Babel preset means it supports user plugins) and can be used as a preset or CLI tool. Babili will also be able to make ES2015+ specific optimizations.

Pronunciation

# sounds like "bah billy" or "Babadi" (from DBZ)
say Babili

Babili is Babylon in Akkadian.

If you can’t remember the name, babel-minify works too (made an issue for the name).

Why minify?

At a basic level, minification removes unnecessary characters from a program without changing its functionality – things like comments, whitespace, newlines, and extra parentheses. Advanced minification may transform programs into smaller equivalents and remove redundant/unreachable code.

Minification is primarily useful for decreasing the size of the JavaScript payload sent from the server to the client: users will download less code to use your website. Advanced minification can also result in shorter parse time (less code to parse) and in some cases faster runtime (e.g. advanced optimizations like function inlining).

Current minifiers

We currently use tools like Babel to compile ES2015 code down to ES5 code to support older browsers. Then we use something like Uglify to cut down on the bundle size.

As browsers implement more ES2015 features and we drop support for older browser versions, there is a sliding window of the version of ECMAScript you write in and the target ECMAScript version you minify to. However since Uglify cannot parse ES2015+, you would still have to compile down to ES5 anyway.

Babili

That’s where Babili comes in.

Babili is ES2015+ aware because it is built using the Babel toolchain. It is written as a set of Babel plugins, consumable with the babili preset.

Example

Say we’re targeting the latest versions of Chrome, Firefox, Edge, and Safari – all of which support ES2015 classes. Then, compiling ES2015 classes to a constructor function and prototype methods (ES5) results in more code (and potentially loses any optimizations browsers might have for classes).

Also it’s important to note that this isn’t specific to ES2015. Because Babel updates as ECMAScript updates (with ES2015, ES2016, and now ES2017) and follows the proposal process for experimental features (with our stage-x presets), the minifier should be able to output whatever version of ECMAScript that is supported.

In the future, we might make use of the ES2015+ syntax information we have at compile time (e.g. we know that given function is an arrow function or that a given binding is block-scoped etc) to do advanced optimizations. And we can make use of the knowledge that we’re targeting an ES2015+ environment in creative ways.

One issue with using Babili as a preset is that then Babili would only run per-file rather than on the whole bundle. Minification usually happens after bundling as with the “UglifyJsPlugin” in webpack. However, running it after bundling would lose the speed benefits (needs to be measured) of doing the transpiling/minification in the same step. Again, this is something we need to think about: how to intergrate or pass more information to the bundler.

Babili CLI

If you don’t use Babel, you can use our standalone CLI tool babili. (Currently it’s just a wrapper for babel-cli + the preset). You could run this after transpiling (or not) in place of Uglify.

We want to have a better story with integration with Webpack/bundlers in the near future! Also check out #100.

Pros/Cons

Uglify Pros

No change to existing tooling if you are already minifying.

Battle-tested/production ready (it’s been around for years and has wide adoption (we are all using it)!

It’s super fast and outputs small code already.

Uglify Cons

Custom parser/tooling, so it’s difficult to output/minify ES2015+ and make changes.

Not modular, and currently no way to create own plugins/minification strategies outside of core.

Babili Pros:

ES2015+ aware (nothing special needs to be done because we can use the babylon parser) and Babel will update as standards/browsers update.

Uses the existing Babel toolchain, can consume as a Babel preset or standalone.

Potential for custom smart transforms for React/Flow, etc.

Could use Flow/Typescript annotations to enable advanced minification.

Each minification step can be split into its own plugin, and there’s plenty of options for customization. This makes it easier to contribute and to find/submit issues for specific problems. It also means that people can independently create their own experimental plugins before upstreaming them into core.

For example: this just turns true into !0 which is straightforward to write.

Should be an easy transition if people are familiar with transpiling with Babel already.

Babili Cons:

We released it early, so there aren’t many users yet. Early adopters will have to deal with a tool that isn’t as battle-tested as Uglify at first.

Right now, the performance is worse/size is worse than Uglify on our benchmark tests. However, this is something we’ll be focusing on improving.

TL;DR: Babili should be able to keep up with the ECMAScript standard as new features get added as well as target the environments you need to support. It has a lot of potential: it may not be as production-ready as Uglify at the moment since it was just released but as we continue to optimize with more users it should be more than capable.

How to Help

Amjad had been working on this project for a while but we decided to release it earlier as a beta to allow the community to test it out and both contribute through reporting bugs and patches.

It’s still early days for this project so there’s a lot to help out with! Our next priority is to make Babili more stable/robust for a 1.0.0 release.

We will be working to get it as fast and produce code sizes as small as Uglify/Closure Compiler in simple mode.

Testing on more codebases: This will help everyone greatly. Because a minifier runs on all code it has potential for a lot of edge cases/bugs not covered in our basic unit tests. Hopefully we can setup a way to report issues easily; now that the repl supports the minifier it should be easier to reproduce/link bugs. In the future we want options to enable specific plugins so we can pinpoint minimal reproduction steps.

Project infrastructure/maintenance: We want to create more robust benchmarking, setup integration tests on popular open source projects (run the minifier, and then run all the project’s unit tests).

Check the output: If something can be more simplified, it should be straightforward to create an issue and suggest a new transformation to an existing plugin or create a new one. We have the benefit of being modular so anyone can also make their own plugins and then we can figure out whether to include them in the core preset.