babylon

beating Acorn & Esprima in raw performance is very very impressive. But please consider that performance is not the only factor when building parsers. Extensibility is a major concern. Afaik Babylon (used in babel) is a fork of Acorn partly driven by the need for greater extensibility. https://github.com/babel/babylon Another example is espree used in ESLint https://github.com/eslint/espree According to their readme.md espree was based on Esprima and is now using Acorn. Specifically for extensibility reasons. https://github.com/eslint/espree/issues/200

You're absolutely right; Babel's parser is very much hand-coded, and adding syntax requires deep knowledge of the internals. Not impossible, but not for the faint of heart. My dreams of having the safe navigation operator from Coffeescript (a?.b?.c) must yet remain unfulfilled... https://github.com/babel/babylon/blob/master/src/parser/expr...

If you want runtime assertions with flow you can use flow-runtime [0]. Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript. I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that. [0] https://codemix.github.io/flow-runtime/#/ [1] https://github.com/babel/babylon/pull/523#issuecomment-31172...

Yep, and we (Babel) are trying to work with TS on integrating it into Babel similar to how flow works with Babel (parser support + a plugin/preset to strip types). Again, limited resources so if the community really wants it, we would appreciate help in reviewing PRs and testing! https://github.com/babel/babylon/issues/320, https://github.com/babel/babylon/issues/523

This is very close to the way Babylon (Babel's JS parser) works: https://github.com/babel/babylon/blob/7.0/src/parser/express... If anyone in SF is interested in hacking babylon to build a superset of JS, I'm happy to get coffee and share what I've learned building LightScript [0]. It's been a lot of fun. [0] http://lightscript.org

I haven't heard of this either. I guess they just wanted something that worked with minimal effort. Making the plugin and writing/coming up with spec tests takes time but albeit a better effort for the community overall. Maybe we can get more contributors for this effort now? I made an issue for parser support, and after that we can create a babel plugin though https://github.com/babel/babylon/issues/328.

FYI we do have an issue open about TS https://github.com/babel/babylon/issues/320 so that we could eventually support TS in Babel as a plugin and then create the same strip-types-plugin just like Flow.

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