7 ms·

Babili: An ES6+ aware minifier based on Babel

94 points by hzoo 10y ago

okket 10y ago
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
k__ 10y ago
Can this yield smaller bundles?
- Kequc 10y ago
  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__ 10y ago
    What has this to do with TypeScript?
    - anotherthing 10y ago
      Can babili or babel parse TS?
      - pipeep 10y ago
        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.
yladiz 10y ago
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
- tolmasky 10y ago
  At least when it comes to parsers, it makes sense for Babel to want to be "in control" of their destiny here. Its really hard to draw a line between transpiling and parsing, especially when many of the features you are implementing require new syntax. Not having your own parser can make this more difficult (especially considering how unfortunately most "production ready" parsers end up being hand rolled so don't really easily allow "plugins" or "composition" to easily add new syntax). As babel may aim to implement experimental features that may never actually be added to JavaScript, it would be understandable that that may be considered a low priority for a standalone JavaScript parser project while high priority for a transpiling project.
  - yladiz 10y ago
    But my point still stands -- why don't they just work with the acorn developers to get specific features rather than build their own?
    - hzoo 10y ago
      I would like that too! I don't think there have been any features added since the last one with Babel 6 release. Yeah there's multiple JavaScript parsers: esprima, acorn, shift, babylon (uglify has their own parser I think). There was an effort to standardize as well in https://github.com/estree/estree https://github.com/estree/estree. EDIT: However, in Babel 6 there were a few (nice) incompatible changes to the AST which was unfortunate for interop and other tools (https://github.com/babel/babel-eslint https://github.com/babel/babel-eslint had to make a lot of changes). I don't want to speak for him, but I think a lot of the decisions to fork (parser, etc) at the time were most likely made like mentioned above to move faster. And at the time, Sebastian was basically the only one working on it. Maybe more context from his post: https://medium.com/@sebmck/2015-in-review-51ac7035e272#.qcyza49zu https://medium.com/@sebmck/2015-in-review-51ac7035e272#.qcyz...
anonymousguy 10y ago
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 10y ago
  That doesn't appear to replace variable names with shorter versions, or remove dead code, which Uglify and other minifiers do.
anotherthing 10y ago
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.
- hzoo 10y ago
  The way the minifier is currently implemented is just as a babel preset. We figured users would want to use the tool standalone without babel and the simpliest thing we thought of was to wraps babel-cli and pass in the preset. https://github.com/babel/babili/blob/master/packages/babili/src/index.js https://github.com/babel/babili/blob/master/packages/babili/... I was thinking about using bundledDependencies or maybe just running webpack/rollup over the whole thing, feel free to make an issue.
  - anotherthing 10y ago
    `npm install babili` is 33M. Should users know or care what a babel preset is? They just want to minify code.
    - hzoo 10y ago
      Maybe I didn't word that correctly. It was created as a set of babel plugins but because like you said users shouldn't know what a babel preset is we have the cli tool which acts the same as babel-cli so you don't need to do all of that. Yes, it doesn't need to be 33M that's just a result of the way it was used (babel-cli is that big) and I'm saying that it's something that we can fix
      - anotherthing 10y ago
        Any plans to release minified versions of babili? It would probably shave 90% off the install size.
killercup 10y ago
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 10y ago
  One of our future plans is to use type annotations (Flow, but maybe typescript too) to do advanced optimozations.
- deleted 10y ago
  [deleted]
deleted 10y ago
[deleted]
bshimmin 10y ago
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 10y ago
  coming soon... https://prosecco.surge.sh/ https://prosecco.surge.sh/

94 points by hzoo 10y ago

okket 10y ago

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

k__ 10y ago

Can this yield smaller bundles?

Kequc 10y ago
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__ 10y ago
  What has this to do with TypeScript?
  - anotherthing 10y ago
    Can babili or babel parse TS?
    - pipeep 10y ago
      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.

yladiz 10y ago

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

tolmasky 10y ago
At least when it comes to parsers, it makes sense for Babel to want to be "in control" of their destiny here. Its really hard to draw a line between transpiling and parsing, especially when many of the features you are implementing require new syntax. Not having your own parser can make this more difficult (especially considering how unfortunately most "production ready" parsers end up being hand rolled so don't really easily allow "plugins" or "composition" to easily add new syntax). As babel may aim to implement experimental features that may never actually be added to JavaScript, it would be understandable that that may be considered a low priority for a standalone JavaScript parser project while high priority for a transpiling project.
- yladiz 10y ago
  But my point still stands -- why don't they just work with the acorn developers to get specific features rather than build their own?
  - hzoo 10y ago
    I would like that too! I don't think there have been any features added since the last one with Babel 6 release. Yeah there's multiple JavaScript parsers: esprima, acorn, shift, babylon (uglify has their own parser I think). There was an effort to standardize as well in https://github.com/estree/estree https://github.com/estree/estree. EDIT: However, in Babel 6 there were a few (nice) incompatible changes to the AST which was unfortunate for interop and other tools (https://github.com/babel/babel-eslint https://github.com/babel/babel-eslint had to make a lot of changes). I don't want to speak for him, but I think a lot of the decisions to fork (parser, etc) at the time were most likely made like mentioned above to move faster. And at the time, Sebastian was basically the only one working on it. Maybe more context from his post: https://medium.com/@sebmck/2015-in-review-51ac7035e272#.qcyza49zu https://medium.com/@sebmck/2015-in-review-51ac7035e272#.qcyz...

anonymousguy 10y ago

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 10y ago
That doesn't appear to replace variable names with shorter versions, or remove dead code, which Uglify and other minifiers do.

anotherthing 10y ago

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.

hzoo 10y ago
The way the minifier is currently implemented is just as a babel preset. We figured users would want to use the tool standalone without babel and the simpliest thing we thought of was to wraps babel-cli and pass in the preset. https://github.com/babel/babili/blob/master/packages/babili/src/index.js https://github.com/babel/babili/blob/master/packages/babili/... I was thinking about using bundledDependencies or maybe just running webpack/rollup over the whole thing, feel free to make an issue.
- anotherthing 10y ago
  `npm install babili` is 33M. Should users know or care what a babel preset is? They just want to minify code.
  - hzoo 10y ago
    Maybe I didn't word that correctly. It was created as a set of babel plugins but because like you said users shouldn't know what a babel preset is we have the cli tool which acts the same as babel-cli so you don't need to do all of that. Yes, it doesn't need to be 33M that's just a result of the way it was used (babel-cli is that big) and I'm saying that it's something that we can fix
    - anotherthing 10y ago
      Any plans to release minified versions of babili? It would probably shave 90% off the install size.

killercup 10y ago

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 10y ago
One of our future plans is to use type annotations (Flow, but maybe typescript too) to do advanced optimozations.
deleted 10y ago
[deleted]

deleted 10y ago

[deleted]

bshimmin 10y ago

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 10y ago
coming soon... https://prosecco.surge.sh/ https://prosecco.surge.sh/