Reflect.parse (from RE:typeof null)

Claus Reinke claus.reinke at
Mon May 14 03:48:02 PDT 2012

>> it appears that the SpiderMonkey AST has emerged as a de-facto
>> standard.
> Really? I guess there are many more users of Uglify and Esprima is
> growing fast. Personally I never heard of any non-Mozilla uses of the
> SpiderMonkey API, but perhaps you can point to some.

I was merely stating my personal impression. It is difficult to pin
down all the bits of information that contributed to that impression,
but here are some of them:

- not all JS parsers document their AST, but it appears that the 
    SpiderMonkey AST has the largest number of (partial) 
    implementations; most parsers have their own AST (jslint
    and jshint might share their AST by forking) but
    SpiderMonkey, esprima, PanPG, reflect.js, jstr
    all refer to the same AST document.

    Of those, esprima seems the most active. The combination of
    Reflect.parse awareness and esprima being an efficient cross-
    browser implementation is certainly the reason why I think 
    that this AST spec is in the process of winning.

- even though I've moved to JS relatively recently, I've already
    worked with 3 different JS parsers and have written one myself; 

    it just isn't funny anymore: all of them had different ASTs
    and varying support, and I was still missing out on one popular
    JS parser and its community; so I'm in the process of consolidating
    my JS tool efforts on top of esprima, giving up or porting my 
    own code to gain from collaboration;

- some of the people working with or on esprima have been
    working with other JS parsers before, so I assume they, too,
    prefer convergence and sharing over their previous efforts;
    I expect more tools to be converted for use with esprima;

esprima doesn't try to be anything but an efficient, simple, ES
parser. It doesn't define its own AST, special-purpose code has
been moved out of the main branch, so it just aims to be a
common building block for tool builders.

Having different standards compete in the market has its
advantages, but not for the foundations on which tool-builders
base and share their work. Code implementing the ES grammar 
is such a foundation. 

There isn't much added value to be expected from parsing JS
differently, we just need one good parser, one useable AST
format. Depending on half a dozen parsers with slightly 
different ASTs, just because each was popular at a time when
a different JS tool project was started, is slowing down progress,
and adds to complexity and maintenance costs.

Since I used to be among those asking for an ES standard AST,
I just wanted to join this thread by pointing out that de-facto 
standardizing on esprima (or on the Reflect.parse AST it uses)
appears to offer a pragmatic solution to this problem. For my
own tool building purposes, that is sufficient for the moment.

It would be good if the ES test suite included parser-only tests,
though, so that one could test JS frontends that do not have a JS
engine behind them for conformance to the ES spec grammar.

> Also: I think this might be a better topic for the js-tools

As you know, that was one motivation for starting that group.


More information about the es-discuss mailing list