AST in JSON format

Mark Miller erights at
Mon Dec 7 14:29:39 PST 2009

On Mon, Dec 7, 2009 at 7:45 AM, Maciej Stachowiak <mjs at> wrote:
> On Dec 7, 2009, at 7:22 AM, Kevin Curtis wrote:
>> This covers the origin of the idea and some of it's uses:
>> I'm interested in JsonML AST as a DSL target.
>> Hacking the YACC file in jsc to parse the ES5 grammar as expressed in
>> JsonML could yield an (executable) spec of sorts.
> I can see how modifying the AST client-side prior to execution could be
> useful, to implement macro-like processing. But I don't see the use case for
> serializing an AST in JSON-like format, or sending it over the wire that
> way. It seems like it would be larger (and therefore slower to transmit),
> and likely no faster to parse, as compared to JavaScript source code. So
> shouldn't the serialization format just be JS source code?


While potentially useful, I have no interest in these ASTs as a
serialization format nor in a compact AST encoding. I am interested in
having a standard JsonML AST encoding of parsed ES5, and eventually an
efficient and standard browser-side parser that emits these ASTs. Many
forms of JS meta-programming that currently occur only on the server
(e.g., Caja, FBJS, MSWebSandbox, Jacaranda) or have to download a full
JS parser to the client per frame (ADsafe, JSLint, Narcissus,
Narrative JS) could instead become lighter weight client side

Text by me above is hereby placed in the public domain


More information about the es-discuss mailing list