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
http://groups.google.com/group/js-tools?pli=1
As you know, that was one motivation for starting that group.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
