ES6 compilation

[yukulele]

is there a way to compile coffeescript to es6?

[connec]

See #4078 (comment).

[vendethiel]

Yeah, I'm going to close this one as a dup.

[GeoffreyBooth]

@vendethiel, what about the issues raised in my comment? I understand the logic behind “no browsers support ES6/ES2015 fully yet and it’ll be many years before that changes,” but there are legitimate use cases where ES2015, or major parts of it, are supported now:

• Internal web apps where we know that the user will be using Chrome.
• Server-side code running under Node 4+.
• Working with frameworks like Ember.js that require the ES2015 modules syntax. Using backticks for all import and export statements is hardly an ideal solution.

Shouldn’t we stop kicking the can down the road and start planning for how CoffeeScript can support these scenarios? And then the language will be ready whenever enough client-side browsers catch up enough to make untranspiled ES2015 viable.

[carlsmith]

Agreed. The world has changed.

[vendethiel]

The world has changed since Sep 3? It's not like @jashkenas 's answer is from 2012...

[carlsmith]

I wasn't saying you're wrong to close it. I was only agreeing that the current policy doesn't address a lot of users' needs.

[GeoffreyBooth]

@vendethiel, my point was that @jashkenas' answer overlooked the scenarios I listed above.

ES6 features, just like ES5 features, and ES3 features, are supported on a case-by-case basis. Ideally, they should be added as soon as they're widely supported in shipping JavaScript implementations.

Presumably he's referring to client-side web browser support, in which case yes, wide support is a long way off. But CoffeeScript is used in many other places, and some of those other places support ES2015 or large parts of it now, either natively (Chrome latest, Node 4+) or through transpilers (frameworks like Ember.js with Ember-CLI, Meteor, etc.). Ember in particular requires you to use the module import/export syntax, hence the many tutorials on the web explaining how backticks are required to use CoffeeScript with Ember. Say what you will about how I don't need any ES2015 features, aside from modules; I agree that ES2015 adds almost nothing over CoffeeScript. But it would be a hell of a lot easier to debug ES2015 generated by CoffeeScript, with fat arrows and destructuring etc. intact, than it is to debug the current output.

But the bigger picture is that CoffeeScript will gradually lose marketshare and mindshare if it's viewed as being stuck in the past. There needs to be a discussion about how CoffeeScript will eventually support ES2015 as a compilation output target, ideally as an option. That way you can target ES5/ES3 if you're writing for a general web audience today, or you can target ES2015 if you're making a Node module or Chrome extension or Chrome-only internal app or code to be consumed by an ES2015-bandwagon framework like Ember. I can't continue to convince teams to use CoffeeScript if its docs barely acknowledge that ES2015 exists, and say nothing about CoffeeScript's future in relation to ES2015 and future standards.

[yukulele]

ES6 is a logic intermediate between Coffeescript and ES5.
Examples:

arr = [1,2,3,4].map (a)->a*a
class Person
  constructor:(name)->this.name = name
  speak:()->"my name is #{this.name}"

↓

let arr = [1,2,3,4].map(a=>a*a);
class Person{
  constructor(name){
    this.name = name;
  }
  speak(){
    return `my name is ${this.name}`;
  }
}

↓

var arr = [1,2,3,4].map(function(a) {
  return a * a;
});
Person = (function() {
  function Person(name) {
    this.name = name;
  }
  Person.prototype.speak = function() {
    return "my name is " + this.name;
  };
  return Person;
})();

[mnoack]

@GeoffreyBooth I've seen a few of your posts around and completely agree.

Our team uses CoffeeScript, but now they are sadly moving to ES6 for new JS.

They correctly argue major JS frameworks assume you use ES6, because with Babel, ES6 is effectively compatible with all browsers. Thus we expect frameworks will only support ES6 soon enough, and then our ES5 CoffeeScript is STUCK on old JS frameworks.

Even a simple and clear announcement of CoffeeScript planning on compiling to es6 (I know they are investigating it in related issues) would put our team at ease and we'lld stick with CoffeScript.

[GeoffreyBooth]

@mnoack I’ve been finding ways to make CoffeeScript work for now, at least with Ember (last year) and Meteor (now). See this thread. Basically as long as frameworks depend on Babel, and as long as Babel compiles to ES5, CoffeeScript is viable: just write code that would compile into the same ES5 that Babel would output. For example instead of import you can just use require. As far as I can tell CoffeeScript’s class and extends works wherever the ES2015 class/extends is expected. As much as major frameworks “only support” ES2015, they can all be used with ES5 with some very minimal effort (see other thread) and as long as that’s the case, you can use CoffeeScript.