search

kg / js-astcompressor-prototype

Apache License 2.0
85 stars 12 forks source link

Possible move to ESTree? #2

Open RReverser opened 9 years ago

RReverser commented 9 years ago

ESTree is a standard JavaScript AST representation used by most of devtools (parsers - Acorn, Esprima, ..., transformers, transpilers like Babel, etc.).

Looking at your currently used format, it seems to be simple to migrate, and would allow to interoperate with those tools (feed input from alternative parsers or from transpiler's output).

Would you be open for such migration?

chicoxyzzy commented 9 years ago

I believe that interop with ESTree compatible tools will open very cool possibilities

jdalton commented 9 years ago

Related Shift \cc @michaelficarra

RReverser commented 9 years ago

Well, to be honest, Shift is a good & convenient alternative, but not a community standard. /cc @dherman @mikesherov @sebmck

mikesherov commented 9 years ago

Output to multiple formats is always an option. As far as builtin communities go, ESTree makes sense, but shouldn't preclude a long term goal of also supporting Shift.

sebmck commented 9 years ago

Biggest benefit to ESTree is interoperability which Shift does not have (I know an AST converter exists but it's not really the same thing). Is any outside of Shape using Shift anyway?

RReverser commented 9 years ago

@mikesherov It's not about output but more about input (ability to generate WebAssembly from readily transformed AST). Of course, Shift can easily be plugged in as well, since they already have transformer to ESTree AFAIK.

mikesherov commented 9 years ago

@RReverser right. I meant input. :shipit:

michaelficarra commented 9 years ago

@RReverser

ability to generate WebAssembly from readily transformed AST

Shift is designed primarily for being the ideal AST for transformation. I recommend you read our blog post about it (which is a bit dated now) to understand our motivations.

As an example, consider the program var a; for(var b;;);. ESTree represents both var a and var b as VariableDeclaration nodes. Shift chooses to wrap the VariableDeclaration node representing var a in a VariableDeclarationStatement node. This is one part of many considerations that were taken in order to give you the guarantee that you can safely replace any Statement node with any other Statement node. You don't have that or any of the many other important features that make for a decent experience transforming ASTs with ESTree.

Shift is a good & convenient alternative, but not a community standard.

Though you may not want to call it a "community standard" because we haven't received much input from the community during its design, we have always asked for community involvement, and anyone can read, fork, and implement the specification freely because we have licensed it under the Apache 2 license.

Of course, Shift can easily be plugged in as well, since they already have transformer to ESTree AFAIK.

And from ESTree to Shift, so the other way around is just as much a possibility.

I'm not personally opinionated about what format this project accepts, but I don't want the decision to be driven by misinformation from this thread. Also, it seems to me that neither of these formats are ideal given the goals listed in the README. It would probably be best for each community to create a transformation from their preferred AST representation to the one that is actually ideal for this project.

Thanks for the mention, @jdalton.