Feature names are misleading

[domenic]

I know I've mentioned this on Twitter and @sebmck has agreed, but I wanted to make sure it was logged somewhere I could keep track. Please close if it's a dupe.

Naming all future speculative proposals as "es7" is highly misleading. Let's take a look:

• es7.comprehensions: comprehensions are definitely not going to make it into ES2016; they are probably never going to be in ECMAScript.
• es7.classProperties: this proposal does not have consensus and will likely change drastically before making it into ES, if it ever does. It will definitely not be in ES2016.
• es7.functionBind: although I personally like this proposal, it is subject to a lot of bikeshedding and opposition within the committee, and I am unsure that all of it will make it into ES (e.g. maybe only half of it will). Definitely not ES2016.
• es7.asyncFunctions: Microsoft and Google are rooting for it, but it's going to be a race to see if we can get two shipping implementations in time for the November deadline. I doubt it'll make it into ES2016; ES2017 sounds more likely.
• es7.decorators: although this has made great progress in getting consensus, and has a clear runway ahead of it, I've heard of no interest from implementers, so again, unlikely to make it to stage 4. Maybe 2017, maybe 2018. Maybe sunk on some other objections in the meantime.
• es7.exportExtensions: this is something small enough to theoretically make it into ES2016... except nobody implements and ships modules yet, so it's blocked on that. It's really up in the air when modules could start shipping (I don't even want to guess), so I wouldn't be able to say what year this is going to be, except that it's not going to be ES2016.
• es7.objectRestSpread: similar to decorators.
• es7.trailingFunctionCommas: if implementers were interested, this could maybe make ES2016, as it's a small spec delta. But nobody has started or proposed such work, so I am doubtful.
• es7.exponentiationOperator: I believe this has an experimental implementation in Firefox. So its chances are looking reasonable.

So basically 1/9 of the supposed "ES7" features is on track for ES2016, in my personal view at least. Which is totally fine! There will be another ES2017 train next year. Features which receive enough scrutiny and acceptance can get on that train.

But in the meantime, Babel is creating a bad environment by saying that certain features are "ES7". I honestly think that people don't pay attention to the stages; they just say "of course I'd like to enable es7.classProperties; it'll be in ES7, after all, which is the next version!" This kind of "feature marketing" is harmful both to the ecosystem and to Babel's credibility.

My counterproposal would be one of:

Remove the "es7." prefix entirely. Features happen when they happen. Version numbers are a figment of the imagination; implementers implement features independently, without care for which European Computer Manufacturer's Association-stamped Word document those features live in.

Alternately:

Add "nonstandard." prefix to below stage 2, and "proposed." prefix to stage 2 onward, removing the "es7." prefix. This should clearly communicate that these early-stage features are just ideas that someone has, and are just as likely to be weeded out and abandoned by the committee as they are to advance.

[hzoo]

And then change the prefixes as they advance? ex: nonstandard.functionBind to proposed.functionBind to functionBind

[domenic]

Yes.

[sebmck]

Thanks for logging this @domenic. Are you also proposing dropping the es6. prefix? In 6.0.0, proposed/non-standard syntax will be implemented via plugins that can be versioned independently. This will hopefully get around the naming issue all together and will reduce friction when breaking changes are made to the proposals.

[domenic]

Hmm, the es6. prefix doesn't really have many problems associated with it (besides the minor one of ES6 vs. ES2015), so I don't have strong feelings there. I guess it'd be nice to get rid of it in the spirit of "version numbers are meaningless" (e.g. many ES2016 features will be implemented before modules).

[loganfsmyth]

This sounds like a good change to me.

I'll just throw out, I think the es6 prefix is nice because it's an easy way say say whitelist: ['es6'] to enable all ES6 features. We do that because we didn't want to use any newer features, and Babel enables stage 2 proposals by default.

That stuff could be limited by linting too of course, just wanted to add it as a data point.

[sebmck]

@loganfsmyth Alternatively you can set the stage option to 4.

[RickWong]

Is it possible to move away from stages, and publish the experimental implementations as babel plugins in entirely separate npm packages? E.g. babel-decorators, babel-functionbind, babel-asyncfunctions et cetera.

[sebmck]

@RickWong Yep:

In 6.0.0, proposed/non-standard syntax will be implemented via plugins that can be versioned independently.

[inikulin]

Maybe experimental.stage{stageNum}.{featureName} format will be more appropriate? Because currently we have a proposals by year, official spec versions all messed up together. The year notation seems fragile, since you will need to bump years and end-user will not be able to make assumption if he should or not use this feature (we need stage description in the docs, btw). With the stage notation it will be somehow clear which experimental feature more likely will be in the standard.

[sebmck]

Including the stage in the name is even more fragile. It could change multiple times a year.

[inikulin]

@sebmck right. Re-reading the whole thread now I think your idea about moving proposed/experimental features to the separate packages is the best one.

[sebmck]

This will be fixed by Babel 6 which uses the ES2015 naming to refer to plugins that transform ES2015 syntax. All other plugins that relate to experimental/non-standard syntax and transformations are white labelled with just their name.