4 ms·
Another major difference is that Chevrotain does not generate any code, it is a Parsing DSL not a Parser Generator. It is actually implemented with something v
by bd82 11y ago
Another major difference is that Chevrotain does not generate any code, it is a Parsing DSL not a Parser Generator.
It is actually implemented with something very much like Macros, The Grammar’s implementation itself is parsed at runtime in-order to “understand” the grammar’s structure, once the grammar’s structure is known at runtime, capabilities such as
Lookahead calculation / Error Recovery / Dynamically generated syntax diagrams (self documenting) become possible.
This means you just write plain Javascript, not some new language that is later compiled to a runnable JS parser. At first glance this may seem to be of little consequences to the user in terms of functionality. However it does provide many benefits to the user’s development workflow:
1. Easy debugging.
You don’t have to deal with both a grammar and a thousands of lines of generated code, trying to understand how the generated code maps to the grammar and vice versa.
2. Fast feedback loops.
No compile step…
3. No need for a build/packaging step in your central build or worse yet deal with committing generated code to your source control system.
4. No special none Javascript syntax.
Can use your favorite Javascript editor to build your grammar, instead of relying on custom tools or worse yet a simple text editor.
No special syntax to insert code snippets.
- smaudet 11y ago1. Erm. Nobody would say that you should debug assembly code when writing C/C++ code. This is (more or less) a solved problem, its called source mapping. 2. No need to compile anything with JITs and dynamic in-page compilation 3. You need to minify, as a bare minimum. So, you haven't gotten rid of that step. And #2 is just stupid, you wouldn't commit a binary to an SCM 4. Its called JSON. So, again, what benefit do you actually provide, now that we've debunked your 'benefits'?