4 ms·

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

by 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...
  - anotherthing 10y ago
    acorn is an ECMAScript parse library that emits a JSON parse tree. It does its job very well, but doesn't do anything else.
ravenstine 10y ago
Yes, I hate it when projects do this. Along with senseless forking, trying to solve too many problems(especially ones that are already solved) is one of the worst things that can happen to a piece of software.
sotojuan 10y ago
Uglify has had many years to at least attempt to minify ES2015+. They just haven't—it's still an "experimental" branch in their repo: https://github.com/mishoo/UglifyJS2/issues/448 https://github.com/mishoo/UglifyJS2/issues/448 I agree with your comment, but at some point, devs will get impatient.
- beefsack 10y ago
  All the effort put into Babili could have gone into that branch though, either through feature implementation or polishing so it's production ready. It's a wrong assumption to make that free software can only be developed centrally by a project owner.
  - mlsarecmg 10y ago
    This is one of the cases where starting from scratch is probably the better choice. Uglify probably hasn't come near a stable because of the codebase in the first place.
    - liespotter 10y ago
      Yeah, uglify only minifies the majority of javascript on the web and is downloaded a half a million times per day. But clearly you know better.
amasad 10y ago
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 10y ago
  > 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.
  - amasad 10y ago
    >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. Again, this project started at Facebook and we were scratching our own itch (and the React/Babel community's itch). So our target audience is already people using Babel. You're committing the fallacy of thinking about this as an opportunity cost. But the upside for us in modernizing uglify while Babel exists is so little to make it worth it. >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. I'm going to go ahead and assume that you never worked on a parser before. Pluggable parsers is a really hard problem. And none of the existing parsers have support for it. At facebook we supported an esprima fork for years because they wouldn't accept our JSX/Flow patches. If I'm wrong then put your code where your mouth is and benefit the community by creating the first ever generalized pluggable parser.

by yladiz 10y ago

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...
- anotherthing 10y ago
  acorn is an ECMAScript parse library that emits a JSON parse tree. It does its job very well, but doesn't do anything else.

ravenstine 10y ago

Yes, I hate it when projects do this. Along with senseless forking, trying to solve too many problems(especially ones that are already solved) is one of the worst things that can happen to a piece of software.

sotojuan 10y ago

Uglify has had many years to at least attempt to minify ES2015+. They just haven't—it's still an "experimental" branch in their repo: https://github.com/mishoo/UglifyJS2/issues/448 https://github.com/mishoo/UglifyJS2/issues/448 I agree with your comment, but at some point, devs will get impatient.

beefsack 10y ago
All the effort put into Babili could have gone into that branch though, either through feature implementation or polishing so it's production ready. It's a wrong assumption to make that free software can only be developed centrally by a project owner.
- mlsarecmg 10y ago
  This is one of the cases where starting from scratch is probably the better choice. Uglify probably hasn't come near a stable because of the codebase in the first place.
  - liespotter 10y ago
    Yeah, uglify only minifies the majority of javascript on the web and is downloaded a half a million times per day. But clearly you know better.

amasad 10y ago

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 10y ago
> 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.
- amasad 10y ago
  >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. Again, this project started at Facebook and we were scratching our own itch (and the React/Babel community's itch). So our target audience is already people using Babel. You're committing the fallacy of thinking about this as an opportunity cost. But the upside for us in modernizing uglify while Babel exists is so little to make it worth it. >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. I'm going to go ahead and assume that you never worked on a parser before. Pluggable parsers is a really hard problem. And none of the existing parsers have support for it. At facebook we supported an esprima fork for years because they wouldn't accept our JSX/Flow patches. If I'm wrong then put your code where your mouth is and benefit the community by creating the first ever generalized pluggable parser.