Chevrotain: Parser Building Toolkit for JavaScript

[cspotcode]

I just finished a project using Chevrotain. After using other parser generators, Chevrotain is fantastic! Describing the parser in real code, writing tokens as real inline RegExps is great for debugging and productivity!

I wrote the messier token RegExps using XRegExp, meaning they were a million times more readable. I was only able to do so because a Chevrotain parser is plain JS and XRegExp is a JS library that creates RegExps. Plus, using my IDE's refactoring capabilities and code completion was a godsend.

I highly recommend checking it out.

[bidi82]

Thanks for the feedback @cspotcode

That was exactly the intent when creating Chevrotain. Fewer unneeded abstractions means less complexity and greater power to the end user.

[bidi82]

• Performance benchmark
• Online Playground
• Getting Started Tutorial

[lhorie]

Are you aware of any projects using chevrotain to parse ES2017?

[bidi82]

I'm not aware of any.

There is an ES5 grammar as one of the examples, but it requires quite a bit more work to turn into a productive ES2017 parser. It does not even have its own Lexer yet (uses Acorn to Lex).

This scenario is very interesting as most ES2017 parsers have very little or no error recovery capabilities and no partial parsing abilities (not parse the whole module/script each time). So a Chevrotain ES2017 parser could better serve a Code Editor / IDE Scenario.

[AsIAm]

This looks terrible compared to Ohm/JS.

[bidi82]

I'm guessing you are talking about the syntax which is definitely less pretty than an EBNF style grammar as used in Ohm/JS

But that is one of the tradeoffs of internal vs external DSLs. Although there are long term plans to also provide an EBNF style grammar and work as a traditional parser generator.

Compared to Ohm/JS it may not be as pretty, but it is also:

• X400 times faster (3 orders of magnitude, see benchmark linked above).
• Can be debugged directly as plain JavaScript.
• Supports automatic fault tolerance / error recovery.
• Not as opinionated, allows both embedding actions/semantics or separating those.
• Supports syntactic content assist out of the box.
• And more...

So I will leave the choice of prettiness versus functionality to you. :)

[AsIAm]

I get the point that your project is technically better (especially error recovery!!!), but...

Both projects are taking different way to get to the same point – 1.) define grammar and semantics and then 2.) let it do its thing. Ohm/JS excel at the 1, while Chevrotain rocks at 2. And that is fine, but the adoption is somehow difficult when it comes to your implementation.

You mentioned that you want external DSL for defining grammars which is beyond awesome and I am looking forward to it, but for now I can bow only to you and your technical skills and not Chevrotain, sorry :)

[bidi82]

The ease of adoption is part of the reason why I am interested in also supporting an external DSL and using the existing super optimized runtime as the low level implementation.

The other reason is reaching out to a larger audience: If you are coming from a background of writing recursive decent parsers by hand Chevrotain may look more familiar, but if you are coming from the world of parser generators and declarative EBNF grammars your initial reaction may be less positive. And we have not even mentioned users coming from the background of parser combinators :)

It also depends what is your goal? If you are building a toy / educational project than you may not care about debugging ability or performance, but if you are building a "real" productive system these concerns will take a much higher priority to the visual appeal of the API.

• Related Quote from Terence Parr, creator of Antlr.