Yup, the design of the language is intended to give you the same kind of dynamism and small-as-possible model size that you have with the language model generation tools, and I think it’s also better to be able to read the logic in plain language for maintenance/tweaking reasons, particularly if it may be worked on by someone who doesn’t know the JSGF spec someday.
In stock OpenEars, the grammar language actual results in a well-formed JSGF file being output (in RuleORama, the same grammar language is used but the endpoint isn’t a JSGF file, so probably it’s a good idea to think of the output file type as an implementation detail rather than a promise) so the engine complaining that the JSGF is too big is interesting to me. Are you sure your direct-to-JSGF version and your OpenEars grammar language version are the same rules?
The grammar language doesn’t get nearly the road-testing that language model generation gets because even though it’s more flexible than writing JSGF, it’s still notably harder to use than submitting an NSArray of words, which means that bugs can appear (there is currently one with switching between JSGFs which I expect to have fixed in the upcoming version – right now you have to stop the engine and start again with a new JSGF, which doesn’t have a big time impact but is more complex to write than it needs to be). Let me know about any unexpected results like the one you’ve described.