Reflect.parse (from RE:typeof null)

John J Barton johnjbarton at
Thu May 10 09:21:17 PDT 2012

On Thu, May 10, 2012 at 8:28 AM, Claus Reinke <claus.reinke at> wrote:
>>> Will Reflect.parse be standardized?
>> Maybe. It's too late for ES6 and different implementations have different
>> concrete parse trees, I bet -- although perhaps they all agree on concrete,
>> there's still the question of mapping to abstract. This needs more time to
>> bake.
>> It's also a mouth to feed, not as much as a second built-in parser but it
>> takes its maintenance toll feeding over time. More time needed to get
>> implementor buy-in on this count.
> In the absence of an ES standard for Reflect.parse, for reasons
> documented in this strawman page:
> 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.

> There was just too much pressure for this not to happen, as one cannot even
> test a standalone parser without some way to represent its output. Parser
> implementors and parser users needed a target spec, and the SpiderMonkey AST
> was the best
> known, and the only one with engine-maker buy-in.
> So, the concerns about not forcing different vendors to support
> a standard AST API have led to one vendor "owning" the standard..
> Given the speed of parsers like esprima, and the performance
> and complexity implications of other engine's internal ASTs
> not matching the SpiderMonkey AST, it does seem right not
> to force engine makers to implement Reflect.parse.
> The question is: how to move this de-facto standard forward?

Extend esprima or compete with it.

> For instance, there is an esprima branch implementing modules,
> does it have to wait for someone (Mozilla?) to extend the AST spec?

No, that's the beauty of non-standards.

>  Or does
> the feature get merged into the master, and
> everyone has to change when Mozilla implements?

Each project gets to make their own decisions.

> Similarly for other parts of
> the evolving ES6 spec.

> Or, there are issues emerging from the increasing use of the
> AST API - will everyone have to apply to Mozilla for changing
> the spec?

No, that is the beauty of de-facto standards.

> Will Mozilla do that if it means changing their
> implementations?

We don't need to care.

> Do they now have to pay the maintenance
> toll mentioned above?

It's their choice.

I think you are putting the cart in front of the horse. We don't have
enough experience with JS dev tools to know which AST is best. We need
to build some. We need some competition between esprima, uglify etc.
Then we can make informed decisions about AST API.  Really the AST API
is not the biggest barrier to tools.  Just pick one. I tried uglify,
it's fast but the API takes some getting used to. I tried Traceur
(because I know the traceur maintainer) and the API is wonderful, even
if the parser is not as fast. However it supports error handling well.
The Esprima API (based on the SpiderMonkey API) looks very similar to
Traceur's and it's parser has a reputation of being fast but no error
recovery. What is your experience?

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


More information about the es-discuss mailing list