ES6 support

[lolmaus]

I've started a discussion on the ES6 future of CoffeeScript here. Let me quote the introduction:

ES6 is gaining a lot of spread. It introduces a lot of new concepts into JS. Here are nice overviews: short, comprehensive.

And people already use those features! Thanks to the effort from such projects as 6to5, es6-transpiler and Traceur, for a modern JS developer who does not use CoffeeScript, there is simply no reason not to use ES6 nowadays. Many modern JS projects are already being written in ES6. Moreover, popular JS frameworks already demand that their users code in ES6 out of the box (this includes Angular 2 and EmberJS).

CoffeeScript is essentially locked at ES5. Some ES6 features are accessible via backticks, but others directly conflict with the CoffeeScript syntax, including said backticks. With CoffeeScript's main contributors having explicitly refused to support ES6, CoffeeScript is doomed to become a thing of the past.

I wonder what is the position of CoffeeScriptRedux maintainers on ES6 support. If CoffeeScriptRedux introduces full ES6 support, it is able to take CoffeeScript over completely.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7936885-es6-support?utm_campaign=plugin&utm_content=tracker%2F33145&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F33145&utm_medium=issues&utm_source=github).

[lolmaus]

The problem with ES6 support in CoffeeScript is that ES6 overlaps with CoffeeScript syntax. Some of core CS features conflict with ES6, namely backticks and fat arrows, others become redundant (splats, comprehensions, classes, etc). I think that the JS preprocessor of the future should not have its syntax elements mean things different from the modern JS.

I can think of three directions:

• CoffeeScriptRedux maintainers refuse to support ES6. CoffeeScriptRedux dies out together with CoffeeScript and some other ES6-capable preprocessor takes its place.
• CoffeeScriptRedux extends CoffeeScript syntax to support ES6. Nothing is deprecated, but identical syntax elements mean different things than those of the contemporary JavaScript. This makes CoffeeScript an even more hated language.
• CoffeeScriptRedux team decides to start a new preprocessor project, giving precedence to ES6 syntax features. The new preprocessor is as easy to learn for a ES6 user an CoffeeScript was for a ES5 user. Can't be used to compile CoffeeScript, but who needs ES6 support in old projects anyway.

What do you say?

[erisdev]

• CoffeeScriptRedux maintainers pull their heads out of the sand and fix the language so that it matches ES6 semantics, breaking backwards compatibility—it is CoffeeScript's "2.0" after all, and breaking changes have already been made. CoffeeScript in the mean time remains compatible with legacy code. The CoffeeScriptRedux compiler is renamed coffee2 or some such shit in order to coexist alongside the already mutually incompatible coffee.

Though frankly I'm considering just making a fork with a new name and fixing this myself.

[eventualbuddha]

Or you can just jump on the ES6 bandwagon, and help me build a tool to convert CoffeeScript to ES6 😉 I'm using CoffeeScriptRedux to make the necessary modifications to the source code.

[erisdev]

Maybe when ES6 ditches the curlies for indentation. 😝

[eventualbuddha]

Never going to happen 😉

[sleepyfox]

I would consider that since active development stopped on this project almost 11 months ago (according to the commit log) that any major requests for change are going to fall on deaf ears.

[CodisRedding]

R.I.P

[devinrhode2]

I think we should focus on creating IDE and editor plugins that automatically and flawlessly insert es cruft for you, color it so it's hard to see (because you don't need to), let tc39 innovate the language, and libraries focus on making nice API's for one js.

In the meantime, recognizing import, export, and default as valid tokens and passing them through into the output would be a real painkiller for coffeescript-ember devs right now. This would allow @alexspeller to deprecate his coffees6 hack, and the ember community could use happily use coffeescript with the standard ember-cli-coffeescirpt plugin without the ugly escaped imports and exports.

@michaelficarra Any pointers as to how we could let the import, export, and default keywords pass through into the output?

[michaelficarra]

@devinrhode2: "passing through" breaks the abstraction, and is not how this compiler works. It is a structural transformation, not a text-based one. Sure, we could easily add support for import/export declarations, but the implementation would probably not look like what you're thinking.

[eventualbuddha]

I think if you want to add support for import and export statements you should either for CSR and add support to the parser, or continue using a hack to fix it.

The "right" solution, in my opinion, is to move to ES6 using decaffeinate to translate from CoffeeScript to ES6, and babel to transpile from ES6 to ES5.

(I am a contributor to babel and the maintainer of decaffeinate, fwiw.)

[alexspeller]

The "right" solution, in my opinion, is to move to ES6 using decaffeinate to translate from CoffeeScript to ES6, and babel to transpile from ES6 to ES5.

ES6 is certainly is an improvement, but still nowhere near as nice to code in as coffeescript. It would still make a lot of sense, for people who like coffeescript, to have a way to make use of ES6 modules in coffeescript

[eventualbuddha]

@alexspeller I think your coffees6 project does just that. Since CoffeeScript itself does not have, and will likely never have, support for ES6-style modules it necessarily means using a fork or a hack to make it work. I guess I'm not seeing what's wrong with the status quo for those who choose to use CoffeeScript.

[vendethiel]

What? Why would coffee never see es6 modules going through? Did jeremy say that?

[alexspeller]

@eventualbuddha it seems like coffeescript is very likely to have ES6 modules eventually, just not immediately

A fork has obvious issues of keeping up to date with the latest version. A hack has issues of being a hack (regex substitution has a lot of caveats compared to real parsing). But it probably is the best compromise for now.