New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project scope and future #568

Closed
kittens opened this Issue Jan 22, 2015 · 78 comments

Comments

Projects
None yet
@kittens
Member

kittens commented Jan 22, 2015

6to5 has gone a long way in a few short months, since then I've learnt a lot of about maintaining an open source project as well as discovered what I see as shortcomings in the current ecosystem and environment.

There are a lot of complaints about 6to5 not being "future proof". Many are under the assumption that 6to5 will be a stopgap solution until ES6 is supported. I don't agree. I believe that there are things that 6to5 can expand upon to not only become future proof but to potentially influence future standards. 6to5 will always be necessary if you want next generation features, whether this is JSX, ES6, ES7, whatever, support and features can be added more quickly to 6to5 than it can in browsers and environments mainly because 6to5 only has to operate on a subset of the constraints placed on vendors.

Future

Ideally I'd like for 6to5 to be a more general JavaScript of the future transpiler. 6to5 already supports Flow/JSX as well as experimental ES7 features so the name isn't even representative of the project in it's current state although it is in how it's widely used.

A JavaScript transpiler based on future standards and specifications, whether ECMAScript or not, I think is an extremely noble goal. I think there's a large use case for 6to5 beyond just ES6. Having an interopable platform to base code transformations on I think is a very powerful idea. This may mean exposing a very feature-rich core that contains transforms or even exposing a public API.

Some of the decisions will need to be extremely calculated in order to provide a concise and specific goal. I'm well aware of the technical challenges associated with this, feature creep, maintenance etc. I'm not going to put a timeline on any of this. It could be in 3, 6, 12 months, the time is ultimately arbitrary, I'm looking for more general feedback on the concept rather than when it'll be appropriate.

What now?

Please let me know your thoughts, I'm extremely eager to get as much community feedback as possible. I have thoughts on how to go about doing a lot of this, including a modular parser etc that I'll elaborate on if necessary. Thanks to everyone who decides to leave feedback and criticism!

/cc @thejameskyle @eventualbuddha @stefanpenner @gaearon @AluisioASG @ocombe @amasad @timoxley @dashed @monsanto

@kittens kittens added the discussion label Jan 22, 2015

@amasad

This comment has been minimized.

Show comment
Hide comment
@amasad

amasad Jan 22, 2015

Member

first off, congrats on the success of the project and thank you (and contributors) for moving really fast on improving and fixing bugs! 💃 💃

6to5 will always be necessary if you want next generation features, whether this is JSX, ES6, ES7, whatever,

+1, JavaScript will even become a faster moving language with ES7 and beyond as they'll have a faster release cycle and transpilers will always be needed. It's unfortunate that the name implies a specific version, however, you can always reverse engineer a new acronym (or change the name)

Having an interopable platform to base code transformations on I think is a very powerful idea. This may mean exposing a very feature-rich core that contains transforms or even exposing a public API

Agreed. All the language extensions that came out of Facebook where once experimental internal transforms before they became proposals (es7 spread) or community standards (JSX). Additionally, we do have profiling and other transforms that we'll continue to change and add to. And having an extensible and fast transpiler with a nice API for writing proprietary transforms will always be needed.

including a modular parser etc that I'll elaborate on if necessary

Please do. The parser story in JS is a bit of an unfortunate one at this point. The more parsers we have the harder it will become to make sure all of them are correct and are up-to-date. So I'm interested to hear about what you have in mind.

Member

amasad commented Jan 22, 2015

first off, congrats on the success of the project and thank you (and contributors) for moving really fast on improving and fixing bugs! 💃 💃

6to5 will always be necessary if you want next generation features, whether this is JSX, ES6, ES7, whatever,

+1, JavaScript will even become a faster moving language with ES7 and beyond as they'll have a faster release cycle and transpilers will always be needed. It's unfortunate that the name implies a specific version, however, you can always reverse engineer a new acronym (or change the name)

Having an interopable platform to base code transformations on I think is a very powerful idea. This may mean exposing a very feature-rich core that contains transforms or even exposing a public API

Agreed. All the language extensions that came out of Facebook where once experimental internal transforms before they became proposals (es7 spread) or community standards (JSX). Additionally, we do have profiling and other transforms that we'll continue to change and add to. And having an extensible and fast transpiler with a nice API for writing proprietary transforms will always be needed.

including a modular parser etc that I'll elaborate on if necessary

Please do. The parser story in JS is a bit of an unfortunate one at this point. The more parsers we have the harder it will become to make sure all of them are correct and are up-to-date. So I'm interested to hear about what you have in mind.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 22, 2015

Member

congrats on the success of the project and thank you (and contributors) for moving really fast on improving and fixing bugs! 💃 💃

Thanks! It's surreal to see your crappy sideproject turn into something that people are actually interested in and want to use.

It's unfortunate that the name implies a specific version, however, you can always reverse engineer a new acronym (or change the name)

The name is definently going to be changed. Not sure when, not sure what to, but it's definently something I want to do.

Additionally, we do have profiling and other transforms that we'll continue to change and add to. And having an extensible and fast transpiler with a nice API for writing proprietary transforms will always be needed.

Is there currently a platform that you use to develop these already? ie. jstransform, recast

Please do. The parser story in JS is a bit of an unfortunate one at this point. The more parsers we have the harder it will become to make sure all of them are correct and are up-to-date. So I'm interested to hear about what you have in mind.

Basically something similar to acornjs/acorn#168. It'd involve creating yet another parser but it's really the only way in order to properly integrate a solid Parser API. As mentioned in that issue, various hooks would be placed around the "core" parser that shell out behaviour to various submodule parsers. The main hurdle would be performance though, maintaining the performance of acorn (or another parser) while retaining the pluggability would be a difficult problem to solve.

Member

kittens commented Jan 22, 2015

congrats on the success of the project and thank you (and contributors) for moving really fast on improving and fixing bugs! 💃 💃

Thanks! It's surreal to see your crappy sideproject turn into something that people are actually interested in and want to use.

It's unfortunate that the name implies a specific version, however, you can always reverse engineer a new acronym (or change the name)

The name is definently going to be changed. Not sure when, not sure what to, but it's definently something I want to do.

Additionally, we do have profiling and other transforms that we'll continue to change and add to. And having an extensible and fast transpiler with a nice API for writing proprietary transforms will always be needed.

Is there currently a platform that you use to develop these already? ie. jstransform, recast

Please do. The parser story in JS is a bit of an unfortunate one at this point. The more parsers we have the harder it will become to make sure all of them are correct and are up-to-date. So I'm interested to hear about what you have in mind.

Basically something similar to acornjs/acorn#168. It'd involve creating yet another parser but it's really the only way in order to properly integrate a solid Parser API. As mentioned in that issue, various hooks would be placed around the "core" parser that shell out behaviour to various submodule parsers. The main hurdle would be performance though, maintaining the performance of acorn (or another parser) while retaining the pluggability would be a difficult problem to solve.

@amasad

This comment has been minimized.

Show comment
Hide comment
@amasad

amasad Jan 22, 2015

Member

Is there currently a platform that you use to develop these already? ie. jstransform, recast

yes, mostly jstransform, there are things that we're blocked on because at it's current form it doesn't support all the things that ast->ast transform can do.

Member

amasad commented Jan 22, 2015

Is there currently a platform that you use to develop these already? ie. jstransform, recast

yes, mostly jstransform, there are things that we're blocked on because at it's current form it doesn't support all the things that ast->ast transform can do.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 22, 2015

Member

A public transformer API is worth pursuing then since transformers can be pretty versatile and compact. Such as optional.undeclaredVariableCheck, spec.illegalTopLevelThis and es6.constants for example.

Member

kittens commented Jan 22, 2015

A public transformer API is worth pursuing then since transformers can be pretty versatile and compact. Such as optional.undeclaredVariableCheck, spec.illegalTopLevelThis and es6.constants for example.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 22, 2015

Member

I decided to switch to use 6to5 when I saw zero-pain builtin JSX and Flow support and ES7 goodies. I heard this as “we're not afraid to experiment in core and we're not dogmatic purists”, which compelled me to switch. I hope 6to5 retains its spirit of trying out good concepts at fast pace wherever they come from.

Member

gaearon commented Jan 22, 2015

I decided to switch to use 6to5 when I saw zero-pain builtin JSX and Flow support and ES7 goodies. I heard this as “we're not afraid to experiment in core and we're not dogmatic purists”, which compelled me to switch. I hope 6to5 retains its spirit of trying out good concepts at fast pace wherever they come from.

@ocombe

This comment has been minimized.

Show comment
Hide comment
@ocombe

ocombe Jan 22, 2015

Modularity is often the key to success for open source projects. It helps the project grow, it can answer to many use cases and when people want something too specific they can to write their own addon.
Even if there is a small performance loss by making a lot of parts optional (and I'm not sure there would be), the fact that you can opt out of things that you don't need (JSX/Flow for example) will make up for it. In the end it might even be faster.

I heard that you're merging 6to5 with esnext, it might be a good time to rename the project.

ocombe commented Jan 22, 2015

Modularity is often the key to success for open source projects. It helps the project grow, it can answer to many use cases and when people want something too specific they can to write their own addon.
Even if there is a small performance loss by making a lot of parts optional (and I'm not sure there would be), the fact that you can opt out of things that you don't need (JSX/Flow for example) will make up for it. In the end it might even be faster.

I heard that you're merging 6to5 with esnext, it might be a good time to rename the project.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 22, 2015

Member

BTW I'm really happy 6to5 went Webpack over Browserify kind of modularity, at least for now—it would've been painful to have all these transforms as separate packages and have to “build your own 6to5”. Even if in future we want more pluggable transforms, IMO it's best to retain beginner-friendly batteries-included approach.

Member

gaearon commented Jan 22, 2015

BTW I'm really happy 6to5 went Webpack over Browserify kind of modularity, at least for now—it would've been painful to have all these transforms as separate packages and have to “build your own 6to5”. Even if in future we want more pluggable transforms, IMO it's best to retain beginner-friendly batteries-included approach.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 22, 2015

Member

@ocombe 6to5 already merged with esnext a month ago. A name change is appropriate but not to esnext which is what I assume you're proposing.

@gaearon Yeah, I'm leaning more towards a powerful transformer API with everything else built-in. Meaning that all official transformers would be in the main package by default and only third party ones would be available elsewhere. I think this is a problem that esnext suffered from, having the main package contain all the modules but also having them all available separately, at least for me, made it very confusing.

Member

kittens commented Jan 22, 2015

@ocombe 6to5 already merged with esnext a month ago. A name change is appropriate but not to esnext which is what I assume you're proposing.

@gaearon Yeah, I'm leaning more towards a powerful transformer API with everything else built-in. Meaning that all official transformers would be in the main package by default and only third party ones would be available elsewhere. I think this is a problem that esnext suffered from, having the main package contain all the modules but also having them all available separately, at least for me, made it very confusing.

@ocombe

This comment has been minimized.

Show comment
Hide comment
@ocombe

ocombe Jan 22, 2015

It's been a month already? Oh man!
No I wasn't suggesting to change it to esnext, just that merging 2 projects would result in a new entity [name to be defined] :)

ocombe commented Jan 22, 2015

It's been a month already? Oh man!
No I wasn't suggesting to change it to esnext, just that merging 2 projects would result in a new entity [name to be defined] :)

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 22, 2015

Member

@ocombe The merger was done weeks before it was publicly announced 😜

Member

kittens commented Jan 22, 2015

@ocombe The merger was done weeks before it was publicly announced 😜

@ocombe ocombe referenced this issue Jan 22, 2015

Closed

atScript support #559

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Jan 22, 2015

I think it's super important to keep the project as standards compatible as possible so while it might not be a stop gap there will be several stop gaps. This project is amazing work and we enjoy using it. I think that a focus should also be producing faster more optimised ES5 code.

I'd also really love to see live-compilation improve. Ideally if it was only a few milliseconds I wouldn't mind the hit of 6to5 on IE10 for instance knowing that other browsers I support will run ES6 code. If I can truly develop ES6 and get 'older browsers' out of the way sacrificing a bit of performance that's awesome for me.

Also allowing easily extending the syntax from the outside of 6to5 would be a great way to test out proposals and new ideas. You've done great work enabling new proposals but it can be even better.

benjamingr commented Jan 22, 2015

I think it's super important to keep the project as standards compatible as possible so while it might not be a stop gap there will be several stop gaps. This project is amazing work and we enjoy using it. I think that a focus should also be producing faster more optimised ES5 code.

I'd also really love to see live-compilation improve. Ideally if it was only a few milliseconds I wouldn't mind the hit of 6to5 on IE10 for instance knowing that other browsers I support will run ES6 code. If I can truly develop ES6 and get 'older browsers' out of the way sacrificing a bit of performance that's awesome for me.

Also allowing easily extending the syntax from the outside of 6to5 would be a great way to test out proposals and new ideas. You've done great work enabling new proposals but it can be even better.

@ocombe

This comment has been minimized.

Show comment
Hide comment
@ocombe

ocombe Jan 23, 2015

ES6 is dead, it's ES2015 now, so 6to5 should be 2015to5... hmm time to rename the project ! 😄

ocombe commented Jan 23, 2015

ES6 is dead, it's ES2015 now, so 6to5 should be 2015to5... hmm time to rename the project ! 😄

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Jan 23, 2015

Member

my suggestion is naming it as something decoupled from version, something like esnext or jsnext (or something along those lines)

Member

stefanpenner commented Jan 23, 2015

my suggestion is naming it as something decoupled from version, something like esnext or jsnext (or something along those lines)

@jsoverson

This comment has been minimized.

Show comment
Hide comment
@jsoverson

jsoverson Jan 23, 2015

@sebmck congrats on 6to5, it's working well for us.

including a modular parser

It may be worth reaching out to @ikarienator and his work on parser combinators and the Shift AST.

jsoverson commented Jan 23, 2015

@sebmck congrats on 6to5, it's working well for us.

including a modular parser

It may be worth reaching out to @ikarienator and his work on parser combinators and the Shift AST.

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Jan 23, 2015

Contributor

For the parser, maybe checkout the fresh esprima fork, espree that plan to get full support for es2015 asap (see eslint/espree#10).

Contributor

MoOx commented Jan 23, 2015

For the parser, maybe checkout the fresh esprima fork, espree that plan to get full support for es2015 asap (see eslint/espree#10).

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 23, 2015

Contributor

Don't rename, the ES6 name stuck while its feature set was frozen. And don't rename even if someone else decides to call it something else when there's no new feature change (e.g. ES2015) 😄

Contributor

dashed commented Jan 23, 2015

Don't rename, the ES6 name stuck while its feature set was frozen. And don't rename even if someone else decides to call it something else when there's no new feature change (e.g. ES2015) 😄

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 23, 2015

Member

@MoOx Thanks! The 6to5 parser is already more feature complete and supports more than espree so that's not the issue.

@dashed A rename is still necessary regardless.

Also just so we're clear, the name "esnext" is not appropriate. Not only is it ambiguous but as per my original proposal, it doesn't adequately describe the direction I want to take nor the current status of this project (React, JSX, Flow etc).

Member

kittens commented Jan 23, 2015

@MoOx Thanks! The 6to5 parser is already more feature complete and supports more than espree so that's not the issue.

@dashed A rename is still necessary regardless.

Also just so we're clear, the name "esnext" is not appropriate. Not only is it ambiguous but as per my original proposal, it doesn't adequately describe the direction I want to take nor the current status of this project (React, JSX, Flow etc).

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 23, 2015

Contributor

@sebmck Out of curiosity, do you have a name in mind? With your ambitious vision for what 6to5 will become, I think the name shouldn't contain cues that subtly reflect towards anything JS (e.g. ES-); and you should probably come up with a random name much in the same manner as istanbul, bluebird, mocha, acorn, etc. Hopefully something that rolls off the tongue well :)

Contributor

dashed commented Jan 23, 2015

@sebmck Out of curiosity, do you have a name in mind? With your ambitious vision for what 6to5 will become, I think the name shouldn't contain cues that subtly reflect towards anything JS (e.g. ES-); and you should probably come up with a random name much in the same manner as istanbul, bluebird, mocha, acorn, etc. Hopefully something that rolls off the tongue well :)

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 23, 2015

Member

@dashed No idea 😜 I guess it's why I didn't want to put a timeline on any of this.

Member

kittens commented Jan 23, 2015

@dashed No idea 😜 I guess it's why I didn't want to put a timeline on any of this.

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Jan 24, 2015

Member

something kickassify

Member

chicoxyzzy commented Jan 24, 2015

something kickassify

@UltCombo

This comment has been minimized.

Show comment
Hide comment
@UltCombo

UltCombo Jan 25, 2015

Name it 20xx, with a mega man logo for maximum credibility.

UltCombo commented Jan 25, 2015

Name it 20xx, with a mega man logo for maximum credibility.

@despairblue

This comment has been minimized.

Show comment
Hide comment
@despairblue

despairblue Jan 25, 2015

👍 love that one :D
On Jan 25, 2015 11:23 PM, "Fabrício Matté" notifications@github.com wrote:

Name it 20xx, with a mega man logo for maximum credibility.


Reply to this email directly or view it on GitHub
#568 (comment).

despairblue commented Jan 25, 2015

👍 love that one :D
On Jan 25, 2015 11:23 PM, "Fabrício Matté" notifications@github.com wrote:

Name it 20xx, with a mega man logo for maximum credibility.


Reply to this email directly or view it on GitHub
#568 (comment).

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 25, 2015

Contributor

Name suggestions:

  • ESEdge
  • JSEdge
Contributor

dashed commented Jan 25, 2015

Name suggestions:

  • ESEdge
  • JSEdge
@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jan 25, 2015

Member

20xx is cool.
But what about Y2.1K?

Member

gaearon commented Jan 25, 2015

20xx is cool.
But what about Y2.1K?

@UltCombo

This comment has been minimized.

Show comment
Hide comment
@UltCombo

UltCombo Jan 25, 2015

Could be "xxxxxxx" for a bit more of future proofness. ;)

UltCombo commented Jan 25, 2015

Could be "xxxxxxx" for a bit more of future proofness. ;)

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 25, 2015

Contributor

Maybe have the name be something related to Transformers. @3rd-Eden suggestions? 😄

Contributor

dashed commented Jan 25, 2015

Maybe have the name be something related to Transformers. @3rd-Eden suggestions? 😄

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 25, 2015

Member

I'd rather this issue not delve into name bikeshedding 😜

Member

kittens commented Jan 25, 2015

I'd rather this issue not delve into name bikeshedding 😜

@UltCombo

This comment has been minimized.

Show comment
Hide comment
@UltCombo

UltCombo Jan 26, 2015

Ideally I'd like for 6to5 to be a more general JavaScript of the future transpiler.

Isn't it already?

I believe 6to5 is quite mature already. A plugins/external transforms API could be nice, but the centralized/batteries-included approach has worked nicely so far.

Sorry, but I don't quite grasp what kind of feedback you're looking for.

UltCombo commented Jan 26, 2015

Ideally I'd like for 6to5 to be a more general JavaScript of the future transpiler.

Isn't it already?

I believe 6to5 is quite mature already. A plugins/external transforms API could be nice, but the centralized/batteries-included approach has worked nicely so far.

Sorry, but I don't quite grasp what kind of feedback you're looking for.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 26, 2015

Member

@UltCombo It is, but the branding hasn't quite caught up and to fully realise this a transformer API is necessary.

Member

kittens commented Jan 26, 2015

@UltCombo It is, but the branding hasn't quite caught up and to fully realise this a transformer API is necessary.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 26, 2015

Member

@UltCombo Mainly just looking for a general 👍 on the overall idea, people are worried about feature creep and have been saying "this is out of scope for this project" which is why I felt the need to detail exactly what this project is and what it's going to be.

Member

kittens commented Jan 26, 2015

@UltCombo Mainly just looking for a general 👍 on the overall idea, people are worried about feature creep and have been saying "this is out of scope for this project" which is why I felt the need to detail exactly what this project is and what it's going to be.

@UltCombo

This comment has been minimized.

Show comment
Hide comment
@UltCombo

UltCombo Jan 26, 2015

👍 JS.next to JS of today is the way to go.

I probably won't make use of features that are not on ECMAScript standard tracks, but I don't mind the transpiler/transformer supporting them. In fact, I found some ideas in the playground pretty nice -- a couple months ago I had the exact same idea for the mallet operator, except for the name heh.

UltCombo commented Jan 26, 2015

👍 JS.next to JS of today is the way to go.

I probably won't make use of features that are not on ECMAScript standard tracks, but I don't mind the transpiler/transformer supporting them. In fact, I found some ideas in the playground pretty nice -- a couple months ago I had the exact same idea for the mallet operator, except for the name heh.

@sparty02

This comment has been minimized.

Show comment
Hide comment
@sparty02

sparty02 Jan 26, 2015

👍 on the transformer API, with a design goal being to allow others to hook up new transformers without having to necessarily crack the hood on the 6to5 source (which may also lessen the entry barrier for those who may be intimidated to get something into the 6to5 core). Also 👍 on the batteries-included approach, but with the suggestion that maybe the 'line in the sand' is to include, by default, only those transforms that represent 'blessed' ES spec items (i.e. those that TC 39 has given the green light). All others may make sense via 'opt-in' only? That being said, I like how you've grouped transforms in v3 (es6, es7, playground, etc).

sparty02 commented Jan 26, 2015

👍 on the transformer API, with a design goal being to allow others to hook up new transformers without having to necessarily crack the hood on the 6to5 source (which may also lessen the entry barrier for those who may be intimidated to get something into the 6to5 core). Also 👍 on the batteries-included approach, but with the suggestion that maybe the 'line in the sand' is to include, by default, only those transforms that represent 'blessed' ES spec items (i.e. those that TC 39 has given the green light). All others may make sense via 'opt-in' only? That being said, I like how you've grouped transforms in v3 (es6, es7, playground, etc).

@jridgewell

This comment has been minimized.

Show comment
Hide comment
@jridgewell

jridgewell Jan 26, 2015

Member

I had the exact same idea for the mallet operator, except for the name heh.

But mallet is way more rememberable than "pipe-pipe-equals". 😄

Member

jridgewell commented Jan 26, 2015

I had the exact same idea for the mallet operator, except for the name heh.

But mallet is way more rememberable than "pipe-pipe-equals". 😄

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 26, 2015

Member

@sparty02 All the current transformers would be included out of the box, I'm not comfortable with splitting everything up and putting it into alternate packages as it reduces barrier to use and makes it hard to maintain. Only stable ES features and JSX/Flow will be enabled by default.

Member

kittens commented Jan 26, 2015

@sparty02 All the current transformers would be included out of the box, I'm not comfortable with splitting everything up and putting it into alternate packages as it reduces barrier to use and makes it hard to maintain. Only stable ES features and JSX/Flow will be enabled by default.

@UltCombo

This comment has been minimized.

Show comment
Hide comment
@UltCombo

UltCombo Jan 26, 2015

@jridgewell hahah nice. My initial idea was something in the lines of "Defaulting assignment operator", but this name would be rather confusing nowadays as default parameters and destructuring defaults only assign a default value when the given value evaluates to undefined, and not falsy. Anyway, mallet is more creative/nicer indeed. 😃

UltCombo commented Jan 26, 2015

@jridgewell hahah nice. My initial idea was something in the lines of "Defaulting assignment operator", but this name would be rather confusing nowadays as default parameters and destructuring defaults only assign a default value when the given value evaluates to undefined, and not falsy. Anyway, mallet is more creative/nicer indeed. 😃

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 27, 2015

Contributor

I'm really liking the eslint project. Since 6to5 will be supporting syntax (e.g .playground) not fully covered by jshint or eslint, it'll be great if 6to5 could be able to provide eslint rules for transformers it exclusively provides. This would make 6to5 very attractive to other devs.

This would entail a separate project, something like 6to5-eslint-rules.

Contributor

dashed commented Jan 27, 2015

I'm really liking the eslint project. Since 6to5 will be supporting syntax (e.g .playground) not fully covered by jshint or eslint, it'll be great if 6to5 could be able to provide eslint rules for transformers it exclusively provides. This would make 6to5 very attractive to other devs.

This would entail a separate project, something like 6to5-eslint-rules.

@despairblue

This comment has been minimized.

Show comment
Hide comment
@despairblue

despairblue Jan 27, 2015

@sebmck by enabling custom transformations would it be possible to use 6to5 as a javascript macro compiler like mozillas sweet.js? I'd love to be able to use something like the contract syntax by contract.js which are implemented as sweet.js macros.

Right now both projects (6to5 and sweet.js) are mutually exclusive, since 6to5 won't parse the custom macros and sweet.js won't parse es6 or es7 features.

despairblue commented Jan 27, 2015

@sebmck by enabling custom transformations would it be possible to use 6to5 as a javascript macro compiler like mozillas sweet.js? I'd love to be able to use something like the contract syntax by contract.js which are implemented as sweet.js macros.

Right now both projects (6to5 and sweet.js) are mutually exclusive, since 6to5 won't parse the custom macros and sweet.js won't parse es6 or es7 features.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 27, 2015

Member

@despairblue Most likely not. It'd require non-trivial parser changes which would require a pluggable parser which has it's own set of engineering hurdles and challenges.

Member

kittens commented Jan 27, 2015

@despairblue Most likely not. It'd require non-trivial parser changes which would require a pluggable parser which has it's own set of engineering hurdles and challenges.

@phpnode

This comment has been minimized.

Show comment
Hide comment
@phpnode

phpnode Jan 28, 2015

Contributor

@sebmck integrating sweet.js itself might not be so difficult, it exposes a sweet.expand() method which returns a list of esprima tokens + hygiene information, any syntax it doesn't understand is passed on through, so it could potentially be used as a pre-transformer.

Contributor

phpnode commented Jan 28, 2015

@sebmck integrating sweet.js itself might not be so difficult, it exposes a sweet.expand() method which returns a list of esprima tokens + hygiene information, any syntax it doesn't understand is passed on through, so it could potentially be used as a pre-transformer.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 28, 2015

Member

@phpnode What do you mean "passed on through"?

Member

kittens commented Jan 28, 2015

@phpnode What do you mean "passed on through"?

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 28, 2015

Member

@dashed How would we provide ESLint rules for syntax that ESLint can't parse?

Member

kittens commented Jan 28, 2015

@dashed How would we provide ESLint rules for syntax that ESLint can't parse?

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 28, 2015

Member

A possible thing I can do is add some delimiters to the parser so anything between certain comments isn't parsed and is just inserted verbatim into the generated output.

// parse:ignore start
blaasdf

asdfer $#$%#@$%!!!!
// parse:ignore end

class Test {

}

which would just transpile to:

blaasdf

asdfer $#$%#@$%!!!!

var Test = function Test() {};
Member

kittens commented Jan 28, 2015

A possible thing I can do is add some delimiters to the parser so anything between certain comments isn't parsed and is just inserted verbatim into the generated output.

// parse:ignore start
blaasdf

asdfer $#$%#@$%!!!!
// parse:ignore end

class Test {

}

which would just transpile to:

blaasdf

asdfer $#$%#@$%!!!!

var Test = function Test() {};
@phpnode

This comment has been minimized.

Show comment
Hide comment
@phpnode

phpnode Jan 28, 2015

Contributor

@sebmck when using .expand(), any tokens that sweet.js doesn't recognise are simply kept intact, but things that it does recognise get transformed, so, you could have a file like this (let's call it input.sjs):

macro test {
  rule {
    $testName:lit $body...
   } => {
    describe($testName, function () $body...)
  }
}

test "hello world" {
  console.log("this is a test");
}

class Foo {
  // sweet.js doesn't support the `class` keyword so this would normally throw if just using .compile()
}

Calling sweet.expand(fs.readFileSync('input.sjs', 'utf8')) will give me back a list of esprima tokens for that file, but the macro will be expanded, so the tokens actually represent this source:

describe('hello world', function () {
    console.log('this is a test');
});

class Foo {
  // sweet.js doesn't support the `class` keyword so this would normally throw if just using .compile()
}

It should then be theoretically possible to pass this on to 6to5 to use as normal.

Contributor

phpnode commented Jan 28, 2015

@sebmck when using .expand(), any tokens that sweet.js doesn't recognise are simply kept intact, but things that it does recognise get transformed, so, you could have a file like this (let's call it input.sjs):

macro test {
  rule {
    $testName:lit $body...
   } => {
    describe($testName, function () $body...)
  }
}

test "hello world" {
  console.log("this is a test");
}

class Foo {
  // sweet.js doesn't support the `class` keyword so this would normally throw if just using .compile()
}

Calling sweet.expand(fs.readFileSync('input.sjs', 'utf8')) will give me back a list of esprima tokens for that file, but the macro will be expanded, so the tokens actually represent this source:

describe('hello world', function () {
    console.log('this is a test');
});

class Foo {
  // sweet.js doesn't support the `class` keyword so this would normally throw if just using .compile()
}

It should then be theoretically possible to pass this on to 6to5 to use as normal.

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 28, 2015

Contributor

@sebmck I'm not familiar with custom eslint rules, as I haven't delved that deep into it yet.

I don't think start/stop delimiters may work, as it may interfere with whitespacing stuff (unsure how much 6to5 tries to preserve).

Contributor

dashed commented Jan 28, 2015

@sebmck I'm not familiar with custom eslint rules, as I haven't delved that deep into it yet.

I don't think start/stop delimiters may work, as it may interfere with whitespacing stuff (unsure how much 6to5 tries to preserve).

@despairblue

This comment has been minimized.

Show comment
Hide comment
@despairblue

despairblue Jan 28, 2015

@phpnode that would also mean that one couldn't use macros inside a class, or a fat arrow function or any other es6 statement, right?

despairblue commented Jan 28, 2015

@phpnode that would also mean that one couldn't use macros inside a class, or a fat arrow function or any other es6 statement, right?

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Jan 28, 2015

Member

@phpnode Are you proposing using sweet.js as the tokenizer for the parser?
@dashed Why would whitespace be an issue?

Member

kittens commented Jan 28, 2015

@phpnode Are you proposing using sweet.js as the tokenizer for the parser?
@dashed Why would whitespace be an issue?

@dashed

This comment has been minimized.

Show comment
Hide comment
@dashed

dashed Jan 29, 2015

Contributor

@sebmck I'm only basing my assumption on this:

// parse:ignore start
blaasdf

asdfer $#$%#@$%!!!!
// parse:ignore end

class Test {

}

but, I figured it may not work so well with in-line stuff.


I'm throwing this as a future thing, but I hope there would be a beautifier transform (i.e. don't transform to ES5). Then it'll be awesome to trivially make a 6to5-beautifier plugin for editors like Sublime Text.

Contributor

dashed commented Jan 29, 2015

@sebmck I'm only basing my assumption on this:

// parse:ignore start
blaasdf

asdfer $#$%#@$%!!!!
// parse:ignore end

class Test {

}

but, I figured it may not work so well with in-line stuff.


I'm throwing this as a future thing, but I hope there would be a beautifier transform (i.e. don't transform to ES5). Then it'll be awesome to trivially make a 6to5-beautifier plugin for editors like Sublime Text.

@chocolateboy

This comment has been minimized.

Show comment
Hide comment
@chocolateboy

chocolateboy Jan 31, 2015

Contributor

@despairblue @phpnode @sebmck 👍 for some kind of sweet.js compatibility/interop (from either side). I'd love to be able to use my two favourite JavaScript enhancers together. Ping @disnet.

Contributor

chocolateboy commented Jan 31, 2015

@despairblue @phpnode @sebmck 👍 for some kind of sweet.js compatibility/interop (from either side). I'd love to be able to use my two favourite JavaScript enhancers together. Ping @disnet.

@phpnode

This comment has been minimized.

Show comment
Hide comment
@phpnode

phpnode Jan 31, 2015

Contributor

Are you proposing using sweet.js as the tokenizer for the parser?

@sebmck maybe, I think it's worth exploring at least, although @natefaubion informs me that there will be some restrictions if we do it that way - you wouldn't be able to use ES6 features within macros. Personally I'd be ok with that tradeoff.

Contributor

phpnode commented Jan 31, 2015

Are you proposing using sweet.js as the tokenizer for the parser?

@sebmck maybe, I think it's worth exploring at least, although @natefaubion informs me that there will be some restrictions if we do it that way - you wouldn't be able to use ES6 features within macros. Personally I'd be ok with that tradeoff.

@disnet

This comment has been minimized.

Show comment
Hide comment
@disnet

disnet Feb 1, 2015

@chocolateboy I've recently been playing around with 6to5 interop in sweet.js on the es6-modules branch (the es6 parser on this branch is up to date). At the moment this just works by a flag that first compiles everything via sweet.js to a string and then passes the string off to 6to5.

Obviously this is not terribly efficient. It would be better if I could just pass a parser API AST to 6to5.

@phpnode note that sweet.expand actually gives you syntax objects which wrap esprima tokens with a lexical context (hygiene) which is probably not appropriate for 6to5 to consume. Better for sweet.js to figure out the hygiene and give an AST. @natefaubion is right that there is a little complication on the sweet.js side to get 6to5 working inside case macros but I think that's pretty straightforward for us (a compiler flag that says run 6to5 before evaling case bodies).

disnet commented Feb 1, 2015

@chocolateboy I've recently been playing around with 6to5 interop in sweet.js on the es6-modules branch (the es6 parser on this branch is up to date). At the moment this just works by a flag that first compiles everything via sweet.js to a string and then passes the string off to 6to5.

Obviously this is not terribly efficient. It would be better if I could just pass a parser API AST to 6to5.

@phpnode note that sweet.expand actually gives you syntax objects which wrap esprima tokens with a lexical context (hygiene) which is probably not appropriate for 6to5 to consume. Better for sweet.js to figure out the hygiene and give an AST. @natefaubion is right that there is a little complication on the sweet.js side to get 6to5 working inside case macros but I think that's pretty straightforward for us (a compiler flag that says run 6to5 before evaling case bodies).

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Feb 1, 2015

Member

@disnet There's actually an API for just passing the AST to 6to5, looks like docs for it was lost with the transition to the new website. require("6to5").transform.fromAST(ast, code, opts);.

Member

kittens commented Feb 1, 2015

@disnet There's actually an API for just passing the AST to 6to5, looks like docs for it was lost with the transition to the new website. require("6to5").transform.fromAST(ast, code, opts);.

@phpnode

This comment has been minimized.

Show comment
Hide comment
@phpnode

phpnode Feb 1, 2015

Contributor

@disnet awesome to hear that you're already playing with this, won't the problem with sweet.js supplying an AST be that it will have to understand all of the syntax 6to5 already supports, e.g. JSX, flow types etc? Or would you consider dropping the current esprima fork in favour of https://github.com/6to5/acorn-6to5 ?

Contributor

phpnode commented Feb 1, 2015

@disnet awesome to hear that you're already playing with this, won't the problem with sweet.js supplying an AST be that it will have to understand all of the syntax 6to5 already supports, e.g. JSX, flow types etc? Or would you consider dropping the current esprima fork in favour of https://github.com/6to5/acorn-6to5 ?

@disnet

This comment has been minimized.

Show comment
Hide comment
@disnet

disnet Feb 1, 2015

@sebmck oh cool! I'll play around with that then.

@phpnode true. Switching to acorn-6to5 wouldn't be enough though. Internally sweet.js builds up its own pseudo-AST to allow macros to match :expr and related pattern classes. We would have to extend the internal structure to understand JSX and other non-standards path extensions.

Philosophically sweet.js wants to recognize and parse standard JavaScript with extensions done via macros (this is the value proposition story of macros, in general compilers don't compose but macros do). So sweet.js and 6to5 can have nice interop on the standardized (or standardizing) subset of JS but if you want to use macros and 6to5 extensions the interop story is less great.

disnet commented Feb 1, 2015

@sebmck oh cool! I'll play around with that then.

@phpnode true. Switching to acorn-6to5 wouldn't be enough though. Internally sweet.js builds up its own pseudo-AST to allow macros to match :expr and related pattern classes. We would have to extend the internal structure to understand JSX and other non-standards path extensions.

Philosophically sweet.js wants to recognize and parse standard JavaScript with extensions done via macros (this is the value proposition story of macros, in general compilers don't compose but macros do). So sweet.js and 6to5 can have nice interop on the standardized (or standardizing) subset of JS but if you want to use macros and 6to5 extensions the interop story is less great.

@kittens kittens referenced this issue Feb 2, 2015

Closed

Name suggestions #596

@jayphelps

This comment has been minimized.

Show comment
Hide comment
@jayphelps

jayphelps Feb 2, 2015

Contributor

sweet.js interop would be HUGE...I'd commit cycles to any effort, ping me if I can help in any way. Otherwise, I'll be experimenting as well.

Contributor

jayphelps commented Feb 2, 2015

sweet.js interop would be HUGE...I'd commit cycles to any effort, ping me if I can help in any way. Otherwise, I'll be experimenting as well.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Feb 2, 2015

Member

I'm extremely open to sweet.js interop. Not quite sure how it'd work but it's worth investigating.

Member

kittens commented Feb 2, 2015

I'm extremely open to sweet.js interop. Not quite sure how it'd work but it's worth investigating.

@disnet

This comment has been minimized.

Show comment
Hide comment
@disnet

disnet Feb 3, 2015

So a couple more thoughts to clarify what directions we could take on sweet.js/6to5 interop.

Sweet.js can generate three things that could be fed to 6to5, a string sweet.compile(), an AST sweet.parse(), or an array of syntax objects sweet.expand() (like @phpnode suggested originally).

The string and AST would both have to be syntactically valid JS (we intend to just follow the current ES-whatever spec) which means if you wanted to use both sweet and 6to5 with extensions like JSX this approach wouldn't work. As I mentioned switching to acorn-6to5 isn't enough and the costs of keeping sweet in sync with 6to5 extensions probably isn't worth it.

The benefit of the string/AST approach is that it works right now (for certain values of "works").

The array of syntax objects is possibly the better choice since sweet.js hasn't yet attempted to parse it so the results can be "syntactically invalid" from the sweet perspective but fine from the 6to5 perspective (e.g. code with JSX). However, this approach does requires 6to5 to understand what a syntax object is.

The basic idea to a syntax object is that it wraps a normal token with its lexical context (which is a lazy set of potential renamings). The reason 6to5 would need to be aware of this is because you need to know the parser context to know if you should ask for the renamed version of an identifier (by calling the sweet function resolve) or ask for its original non-renamed version (by just grabbing the token). For example:

var foo = 42;
var o = {
    foo: foo
}

All three foo syntax objects have the same lexical context but the property foo should not have the renaming and only the parser knows this.

This approach still has some limitations on the sweet.js side since we won't know about 6to5 extensions which limits the kinds of syntax macros can recognize:

macro m {
    rule { $x:expr } => { /* ... */ }
}
// fails to match even though the div is conceptually an expr
var d = m <div className="foo" />

But this probably isn't a huge deal and gets us closer to the ideal than the other approaches.

disnet commented Feb 3, 2015

So a couple more thoughts to clarify what directions we could take on sweet.js/6to5 interop.

Sweet.js can generate three things that could be fed to 6to5, a string sweet.compile(), an AST sweet.parse(), or an array of syntax objects sweet.expand() (like @phpnode suggested originally).

The string and AST would both have to be syntactically valid JS (we intend to just follow the current ES-whatever spec) which means if you wanted to use both sweet and 6to5 with extensions like JSX this approach wouldn't work. As I mentioned switching to acorn-6to5 isn't enough and the costs of keeping sweet in sync with 6to5 extensions probably isn't worth it.

The benefit of the string/AST approach is that it works right now (for certain values of "works").

The array of syntax objects is possibly the better choice since sweet.js hasn't yet attempted to parse it so the results can be "syntactically invalid" from the sweet perspective but fine from the 6to5 perspective (e.g. code with JSX). However, this approach does requires 6to5 to understand what a syntax object is.

The basic idea to a syntax object is that it wraps a normal token with its lexical context (which is a lazy set of potential renamings). The reason 6to5 would need to be aware of this is because you need to know the parser context to know if you should ask for the renamed version of an identifier (by calling the sweet function resolve) or ask for its original non-renamed version (by just grabbing the token). For example:

var foo = 42;
var o = {
    foo: foo
}

All three foo syntax objects have the same lexical context but the property foo should not have the renaming and only the parser knows this.

This approach still has some limitations on the sweet.js side since we won't know about 6to5 extensions which limits the kinds of syntax macros can recognize:

macro m {
    rule { $x:expr } => { /* ... */ }
}
// fails to match even though the div is conceptually an expr
var d = m <div className="foo" />

But this probably isn't a huge deal and gets us closer to the ideal than the other approaches.

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Feb 3, 2015

Member

I'm just conscious of performance. Ideally 6to5 and sweet.js have to be aware of each other to implement any sort of elegant interop. One of the ways I can see this potentailly working out is if acorn-6to5 parses the sweet.js macro syntax and when it encounters it pass it onto some sweet.js API to digest. Might be good to create a new issue to track this so it's more consolidated. I'm skeptical that it can be implemented elegantly.

Member

kittens commented Feb 3, 2015

I'm just conscious of performance. Ideally 6to5 and sweet.js have to be aware of each other to implement any sort of elegant interop. One of the ways I can see this potentailly working out is if acorn-6to5 parses the sweet.js macro syntax and when it encounters it pass it onto some sweet.js API to digest. Might be good to create a new issue to track this so it's more consolidated. I'm skeptical that it can be implemented elegantly.

@jamiebuilds

This comment has been minimized.

Show comment
Hide comment
@jamiebuilds

jamiebuilds Feb 10, 2015

Member

Since this issue was first opened I've been thinking more and more about what 6to5's continued role in the community will be. There has been a bit of confusion in the past as to what will happen with 6to5, which can largely be attributed to its name.

However, the truth is that 6to5 is not going anywhere. Even when ES6/7/2015 is supported across all environments, the excellent work @sebmck and contributors have put into 6to5 will continue to be an important part in the community.

If we look at the current state of JavaScript tooling, there's dozens and dozens of implementations of parsers and transpilers. From compile-to-javascript languages to syntax extensions, from minifiers to beautifiers, linters to code coverage instrumentors, there is a lot of tooling that depends on these two fundamental pieces.

Everyone is constantly re-implementing the same things and it's created an absolute mess, and it's a nightmare for both evolving the language and for beginners to learn/debug.

In the future I think Acorn will largely be the parser of choice for most people (although I'm interested to see what the jQuery foundation does with esprima). Hopefully one of them will become pluggable in the future.

If 6to5 solves the transpiler half of this equation it could unite energy in the community by giving people a common utility to write whatever tool they want.

@sebmck you've spoken to me in the past about how easy it would be for you to add minifying functionality to 6to5, I believe linting was mentioned as well. You've also bragged about how little code it takes to write a new transformer 😜.

Giving people the platform to do that would be awesome.

TL;DR Acorn is to Parsers as 6to5 is to Transpilers

Member

jamiebuilds commented Feb 10, 2015

Since this issue was first opened I've been thinking more and more about what 6to5's continued role in the community will be. There has been a bit of confusion in the past as to what will happen with 6to5, which can largely be attributed to its name.

However, the truth is that 6to5 is not going anywhere. Even when ES6/7/2015 is supported across all environments, the excellent work @sebmck and contributors have put into 6to5 will continue to be an important part in the community.

If we look at the current state of JavaScript tooling, there's dozens and dozens of implementations of parsers and transpilers. From compile-to-javascript languages to syntax extensions, from minifiers to beautifiers, linters to code coverage instrumentors, there is a lot of tooling that depends on these two fundamental pieces.

Everyone is constantly re-implementing the same things and it's created an absolute mess, and it's a nightmare for both evolving the language and for beginners to learn/debug.

In the future I think Acorn will largely be the parser of choice for most people (although I'm interested to see what the jQuery foundation does with esprima). Hopefully one of them will become pluggable in the future.

If 6to5 solves the transpiler half of this equation it could unite energy in the community by giving people a common utility to write whatever tool they want.

@sebmck you've spoken to me in the past about how easy it would be for you to add minifying functionality to 6to5, I believe linting was mentioned as well. You've also bragged about how little code it takes to write a new transformer 😜.

Giving people the platform to do that would be awesome.

TL;DR Acorn is to Parsers as 6to5 is to Transpilers

@kittens

This comment has been minimized.

Show comment
Hide comment
@kittens

kittens Feb 10, 2015

Member

@thejameskyle Couldn't have worded it better myself.

This issue can probably be closed since I've outlined the project direction that I want to pursue and there haven't been any major objections. Thanks everyone for the invaluable feedback and criticism! Very excited for the future.

Member

kittens commented Feb 10, 2015

@thejameskyle Couldn't have worded it better myself.

This issue can probably be closed since I've outlined the project direction that I want to pursue and there haven't been any major objections. Thanks everyone for the invaluable feedback and criticism! Very excited for the future.

@raganwald

This comment has been minimized.

Show comment
Hide comment
@raganwald

raganwald Feb 15, 2015

Contributor

Congratulations. I’m very excited to know that you are committed to being more than just a stopgap measure.

Always have a vision. Why spend your life building other people’s dreams?—Orson Wells

Contributor

raganwald commented Feb 15, 2015

Congratulations. I’m very excited to know that you are committed to being more than just a stopgap measure.

Always have a vision. Why spend your life building other people’s dreams?—Orson Wells

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment