[adamesque]

If I've understood correctly, the most compelling argument (or at least the most seemingly objective one) is that CoffeeScript conflicts with planned features of ES6+, meaning that there is a risk that large CoffeeScript projects will be locked into the ES5 feature set.

Since Discourse is planning on being around long after ES6 becomes widely available, it was a winning argument.

http://meta.discourse.org/t/is-it-better-for-discourse-to-us...

Also, one of the big reasons the Discourse devs liked CoffeeScript is because it makes it hard to commit common JS errors. Building JSHint into their workflow can help bring this protection back.

[jacquesc]

Seems like a very narrow mindset. Why would they assume coffeescript won't adapt to ES6? CoffeeScript compiler can change quickly while maintaining backwards compatibility. ES6 standards move at a snails pace.

There's other perfectly valid reasons to use pure-JS on a large open source project, but the ES6 thing is a red herring IMHO.

[cwp]

What makes you think CoffeeScript can target ES6 while maintaining backwards compatibility? Did you read the discussion? Wycats makes a very good argument for the opposite position.

[jacquesc]

Yep, I did read the discussion. I think wycats brings up a perfectly good concern, but the key point which he misses is that there is time, and CoffeeScript can change to fix what I think is a very solvable issue.

The current estimate for ES6 support in browsers is 2014. CoffeeScript only hit 1.0 about 2 years ago, and has had 3 minor point releases since then.

For me it's not hard to imagine a CoffeeScript 2.0 release at some point next year that targets ES6. It could make a few syntax changes, and ship with some helper tools (or a 3rd would create it) to detect possibilities in your previous code and tell you where you need to tweak to make it compatible.

[cwp]

So, basically, CoffeeScript can't target ES6 while maintaining backwards compatibility, but it doesn't matter, because they have time to manage the transition. Ok, that may well be.

Personally, I agree that ES6 isn't that big an issue, but for a different reason: when they decide they want to take advantage of ES6, they can always make the switch to Javascript then; there's no reason it has to happen now.

[rodw]

CoffeeScript can't target ES6 while maintaining backwards compatibility

Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1]

It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need to change its semantics to match that of ES6? ES6 could introduce a new and different meaning of `for` and `of` (whatever that is) but CoffeeScript could keep its meaning for `for` and `of` (whatever that is). The problem, if any, will be in "wetware".

Isn't the analogy here something like

CoffeeScript is to JavaScript as Closure is to the JVM.

Does Closure break if the JVM adds new features? Why would we expect CoffeeScript to?

[1] Excepting the back-tick delimited escaping for literal JavaScript, but that's not an issue here.

[cwp]

Because of the 1JS principle, ES6 will be a strict superset of ES5. CoffeeScript can maintain its existing semantics, produce the same JS output that it does now, and nothing will break. But then it's not really targeting ES6, is it? It's targeting ES5 and benefitting, as all Javascript code does, from ES6's backward compatibility with ES5.

So sure, if we're not interested in the new features of ES6 in the first place, then I grant that ES6 compatibility is a red herring.

[idle_processor]

Name a couple of said valid reasons?

[nestlequ1k]

1) Open source projects like this would tend to want as many possible contributors as possible. There's more people out there who are comfortable with plain JS than with CoffeeScript.

2) One may prefer a more explicit language, filled with semicolons, curly braces, and "function" functions.

That said, I personally would have greatly preferred it as CoffeeScript, which I use regularly on projects where the people I work with have the same preference.