In the previous tutorial step we have implemented a parser for a "mini" SQL Select grammar. The current problem is that our parser only validates that the input conforms to the grammar. In most real world use cases the parser will also have to output some result or data structure.

We refer to the logic that computes that result or builds that data structure as the Grammar Semantics.


Chevrotain supports two very different solutions to this problem:

Before we continue one of the two approaches must be chosen.

The main difference between the two approaches is in regards to the question: Where are the semantics (user actions) implemented?

When using a CST Visitor the semantics are completely separated from the grammar They could even be implemented in a different file. This has great benefits for the parser's ease of maintenance and its re-usability. Thus using a CST Visitor is the recommended approach.

That is not to say there are no use cases in which embedded actions are better. The main advantage of embedded actions is their performance. Embedded actions are about 50% faster than using a CST Visitor. This may sound like an unbeatable advantage but that is not the case:

  • Chevrotain is so fastopen in new window that even with that performance penalty it would beat other parsing solutions.

    • Tested on Modern V8
  • The Parsing step is normally just one step of a larger flow, a large performance penalty in one step does not equate to a large performance penalty in the whole flow...

Using Embedded actions may also require a better understanding of the Chevrotain Internals. See: Grammar Recording guide.


  • It is recommended to use a CST Visitor to separate the semantics(actions) from the syntax(grammar).
  • Prefer embedding the semantics (actions) in the grammar only in use cases where performance is of utmost concern.

What is Next?

Choose the Semantic actions Model you prefer:

  1. Next step in the tutorial: Semantics - CST Visitor.
  2. Next step in the tutorial: Semantics - Embedded Actions.