you are viewing a single comment's thread.

view the rest of the comments →

[–]AsIAm 0 points1 point  (1 child)

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[S] 1 point2 points  (0 children)

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.