There are going to be some bigger issues if you start targeting ES6, like the inconsistency between for/of in ES6 vs. CoffeeScript, differences in destructuring, semantic inconsistencies in classes, etc.
I'd be very interested to see a proposal for how to deal with that moving forward for CoffeeScript. Will CoffeeScript:
1) ignore new ES6 features that have syntactic overlap with existing CoffeeScript features
2) leave the existing syntax alone and create new syntax that targets the ES6 syntax (for/of means CoffeeScript for/of, while for/inside means ES6 for/of)
3) break backwards compatibility and release a CoffeeScript 2 that targets ES6 and doesn't use syntax that could conflict in the future
There may be another option, but I can't think of it. Knowing exactly which of these options CoffeeScript will take will give me a better understanding of the long-term viability of CoffeeScript.
> Knowing exactly which of these options CoffeeScript will take
> will give me a better understanding of the long-term viability
> of CoffeeScript.
Mmm, nothing like the whiff of uncertainty on a summer evening ;) For starters, you needn't worry -- CoffeeScript already being a heavily forked open-source project, I'm sure there will be versions (whether Coco, Live, Iced, Gorilla, or perhaps a cutely named CoffeES6cript) that track each of the options you've listed.
But you asked about my proposal. I'm most interested in targeting the useful subset of JavaScript that runs across the popular JS platforms at any given moment -- not what may or may not exist in the future, but lives currently as a spec; and also not features that actually exist, but aren't essential (read, harmful, error-prone, nasty), like getters and setters, or E4X (in my opinion, natch).
So in general, what I'd like to see mainline CoffeeScript do, is adopt useful ES6, ES7, and ES8 features, as soon as they land in enough platforms/browsers to be widely useful (yield may be at this point already, or very soon), and to continue to try and find a pleasing minimalist syntax for writing and reading them. If this means taking the ES* syntax wholesale, that's fine. If it means minting a new (and hopefully, but arguably, nicer) syntax, that's fine too. And if it means breaking backwards compatibility, that's also alright, as the compiled lowest-common-denominator JS output will still be perfectly compatible with the new stuff.
Even if CoffeeScript doesn't support ES6 features it will still be a useful in the long term. I'm betting ES3 code generated by CoffeeScript will run fine in a ES6 runtime.
With that said, I'm happy to lose backwards compatibility in lieu of ES6 support. We've already seen forks like IcedCoffeeScript before.
It should be a major jump though, with a migration guide at least. It's similar to the 1.8.7 -> 1.9.2 jump. It's painful, ugly, but for the greater good.
I'd love to see #3. As a user of a language, moving targets are a hassle. It would be clear as day if it was stated that existing CS 1.0 === ES5 (or whatever), CS 2.0 == ES6. This unshackles those working on CS to really fundamentally take advantage of the new features. (Isn't this spirit what drove CS in the first place?)
Comments
There are going to be some bigger issues if you start targeting ES6, like the inconsistency between for/of in ES6 vs. CoffeeScript, differences in destructuring, semantic inconsistencies in classes, etc.
I'd be very interested to see a proposal for how to deal with that moving forward for CoffeeScript. Will CoffeeScript:
1) ignore new ES6 features that have syntactic overlap with existing CoffeeScript features
2) leave the existing syntax alone and create new syntax that targets the ES6 syntax (for/of means CoffeeScript for/of, while for/inside means ES6 for/of)
3) break backwards compatibility and release a CoffeeScript 2 that targets ES6 and doesn't use syntax that could conflict in the future
There may be another option, but I can't think of it. Knowing exactly which of these options CoffeeScript will take will give me a better understanding of the long-term viability of CoffeeScript.
But you asked about my proposal. I'm most interested in targeting the useful subset of JavaScript that runs across the popular JS platforms at any given moment -- not what may or may not exist in the future, but lives currently as a spec; and also not features that actually exist, but aren't essential (read, harmful, error-prone, nasty), like getters and setters, or E4X (in my opinion, natch).
So in general, what I'd like to see mainline CoffeeScript do, is adopt useful ES6, ES7, and ES8 features, as soon as they land in enough platforms/browsers to be widely useful (yield may be at this point already, or very soon), and to continue to try and find a pleasing minimalist syntax for writing and reading them. If this means taking the ES* syntax wholesale, that's fine. If it means minting a new (and hopefully, but arguably, nicer) syntax, that's fine too. And if it means breaking backwards compatibility, that's also alright, as the compiled lowest-common-denominator JS output will still be perfectly compatible with the new stuff.
Thankfully E4X doesn't actually exist anymore (as of FF 21) :)
Even if CoffeeScript doesn't support ES6 features it will still be a useful in the long term. I'm betting ES3 code generated by CoffeeScript will run fine in a ES6 runtime.
With that said, I'm happy to lose backwards compatibility in lieu of ES6 support. We've already seen forks like IcedCoffeeScript before.
It should be a major jump though, with a migration guide at least. It's similar to the 1.8.7 -> 1.9.2 jump. It's painful, ugly, but for the greater good.
I'd love to see #3. As a user of a language, moving targets are a hassle. It would be clear as day if it was stated that existing CS 1.0 === ES5 (or whatever), CS 2.0 == ES6. This unshackles those working on CS to really fundamentally take advantage of the new features. (Isn't this spirit what drove CS in the first place?)