4 ms·

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

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.

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.