3 ms·

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. Ug

by 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.
- deleted 10y ago
  [deleted]
- hzoo 10y ago
  It's not a whole/brand new parser though. It's mostly acorn + JSX/Flow/everything experimental that wouldn't be in acorn anyway (until stage 4) for Babel.
- mstade 10y ago
  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 10y ago
    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.

by amasad 10y ago

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.
deleted 10y ago
[deleted]
hzoo 10y ago
It's not a whole/brand new parser though. It's mostly acorn + JSX/Flow/everything experimental that wouldn't be in acorn anyway (until stage 4) for Babel.
mstade 10y ago
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 10y ago
  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.