
Babili: An ES6+ aware minifier based on Babel - hzoo
http://babeljs.io/blog/2016/08/30/babili?exports=guy
======
yladiz
It may just be a paranoid delusion, but I'm worried that Babel is trying to
become a more encompassing build tool ala Grunt/Gulp instead of just
transpiling. I love Babel and plan to continue to use it in the future for my
front-end development, but the "doing it all ourselves" is a little bit much.

I would much rather see a recommendation and efforts around Uglify than a
brand new minimization tool, and I would rather see work on acorn[1] rather
than around a new parser[2], because these things fragment the community
rather than bring them together.

Edit: Yes, Uglify has taken a long time to get work done on ES2015, but note
that the spec has changed a lot over that time. It does feel like they are
dragging their feet or not getting much done in that front, but all the more
reason to put one of the Babel devs who may have more free time on the project
to get more things going.

1: [https://github.com/marijnh/acorn](https://github.com/marijnh/acorn)

2: [https://github.com/babel/babylon](https://github.com/babel/babylon)

~~~
amasad
We're not losing focus. Babel is as focused as ever on being a general purpose
parser, transformer, and code generator. Babili is a set of Babel transforms.

Uglify has its own parser and transformer and generator, so arguably any work
that goes into that is duplicate work because Babel already covers most of
what it does.

Re parsers: we had to fork acorn because they were understandably skeptical of
adding all the experimental and non-standard features (JSX and flow types)
that Babel supports.

I started this project at Facebook and one of our aims (which is mentioned in
the post) was to have access to the original source AST which may include Flow
type annotations, JSX and early ES proposal features. Have I spent the time
trying to get those into uglify, the majority of the work would've went into
parsing and code generation. And I would imagine an uphill battle with the
maintainers convincing them of adding non-standard features.

~~~
yladiz
> Uglify has its own parser and transformer and generator, so arguably any
> work that goes into that is duplicate work because Babel already covers most
> of what it does.

That seems a little hubristic... Not everyone uses Babel, and working with the
Uglify devs to get it ES2015+ compliant (through whatever means, including
adding a different AST parser) would make the entire community better, not
just Babel. Since not all browsers support ES2015, I have to use babel, but if
I didn't need to use Babel, I wouldn't. But now I'm kind of forced to for
uglification now until ES2015 support comes to Uglify.

> Re parsers: we had to fork acorn because they were understandably skeptical
> of adding all the experimental and non-standard features (JSX and flow
> types) that Babel supports.

JSX and Flow are not part of ES spec. I can understand those being in a
different parser, but that's a flimsy argument for creating a whole new
parser. If you had to create a brand new parser to handle this, it seems like
a Babel issue, not a parser issue.

~~~
mstade
Not sure why you're being down voted, your comment is fine I think.

What's worse than having specific parsers, transformers, and generators – I
think – is not having an AST standard. If there was a common standard for ES
ASTs, including extension points, then it becomes a lot easier to write tools
that aren't specific to a tool chain but specific to a data structure. I could
use the Babylon parser, but do transforms with Rollup and optimizations with
Uglify (obviously provided those tools had APIs that take/return ASTs.)

As it stands, there's a varying degree of lock-in when using these tools,
making them more difficult to compose. That's a shame I think.

~~~
yladiz
You're right -- it would be nice to have a standard AST for ES, which is what
you have in languages like Python, so that tools can be built around it more
easily and without lock-in. This would also help accomplish my idea of helping
the community rather than one tech specifically. I saw some other comment that
mentioned ESTree but I guess that didn't go anywhere... sucks.

------
okket
There is currently a discussion going on about changing the name back to
babel-minify (you can vote)

[https://github.com/babel/babili/issues/124](https://github.com/babel/babili/issues/124)

------
anotherthing
Competition is great. The more minifiers the better.

At a usability level, babili has a 33M install footprint and must be installed
locally in the directory in which you intend to use it.

uglify-js can be installed globally and has a 1.9M install size.

And I've never understood how to configure babel's preset and plugin files.
Why is it necessary for a minifier to do this? Surely this can be greatly
simplified.

~~~
gavinpc
Long live Babel 5.8!

babel@5.8 is faster than babel 6+, can be installed globally and works out of
the box. It just... you know, does what versions 1, 2, 3 & 4 did: compile
ES2015 into ES5. So I just use that. Not every project is a "node" project
that is already dumping megabytes of dependencies into the project directory.
I don't want to have to buy into an entire ecosystem just to use one tool—a
shim, at that.

~~~
ksherlock
I gave up and wrote my own babel cli front end (sudo npm install -g better-
babel-cli) for that very reason.

babel --es2015 --babeli infile.js -o outfile.js.

------
killercup
Interesting, but the only 'Pro' I can actually see here is ES6 support when
you were previously using uglify. I think using Closure Compiler on TypeScript
output with the right JSDoc comments can yield much better results as there is
much more information the minifier can work with.

~~~
amasad
One of our future plans is to use type annotations (Flow, but maybe typescript
too) to do advanced optimozations.

------
k__
Can this yield smaller bundles?

~~~
Kequc
I've been seeing incredibly compressible output from Typescript, if that helps
any. If what you mean by 'bundle' are these 'webpack' things that include css
and images, and all that. Smaller bundle to me would be not to use one at all.

It doesn't seem like webpack's chief concern is file size or simplicity. So if
yours is, just don't use it.

~~~
k__
What has this to do with TypeScript?

~~~
anotherthing
Can babili or babel parse TS?

~~~
pipeep
Babel can parse Flow, which is similar to Typescript. However, Babel doesn't
have any built-in support for inferring or analyzing flow types. However, some
of this type information might be useful in building a more advanced closure-
like minifier.

------
anonymousguy
You don't need Babel or a build process to minify ES6. Pretty Diff has
supported this for years
[http://prettydiff.com/?m=minify](http://prettydiff.com/?m=minify)

~~~
loganfsmyth
That doesn't appear to replace variable names with shorter versions, or remove
dead code, which Uglify and other minifiers do.

------
bshimmin
Ah, are they going to make a minifier based on Bublé
([https://buble.surge.sh/](https://buble.surge.sh/)), too? Perhaps they could
call it Bublili.

~~~
rich_harris
coming soon... [https://prosecco.surge.sh/](https://prosecco.surge.sh/)

