JavaScript parser API

Allen Wirfs-Brock allen at
Wed Jul 6 11:03:49 PDT 2011

On Jul 6, 2011, at 10:02 AM, Claus Reinke wrote:

>>> the AST API strawman ..
>> It hasn't really been championed so far. I was concentrating on
>> other proposals for
> So it was just timing, not behind-the-scenes disagreements. Ok.

I don't think we have any consensus within TC39 WRT whether such an API should be part of some future version Ecma-262.  Personally,  this sounds like library functionality that in the future might manifest as a module.  I think we need to draw a line at adding very many more such libraries to the core standard. For things like this it is too hard to specify them and not clear that there is a single preferred solution.

Everybody would like their favorite library to be "built-in" so there is no loading cost. But there are a huge number of potentially useful libraries and only a few are ever going to get built-in.  Which ones do you choose? Is JavaScript AST generation really the highest priority on the list? What percentage of web applications need to parse JS code?

Rather than pushing for more built-in libraries I think we should all get behind just doing "it" in JS.  To be successful we also need to continue to make JS a more powerful language, with higher performance implementations, and browser hosts with better caching schemes. 


More information about the es-discuss mailing list