Statement regarding CoffeeScript’s relationship with ES2015 and its successors

[GeoffreyBooth]

There should be a statement on coffeescript.org or in this repo’s README explaining how CoffeeScript intends to grow and adapt (or not) in relation to ES2015 and its successors. In particular, will CoffeeScript ever output ES2015 JavaScript? Will it support modules, and if so, how? How will it handle near-equivalents—will it transpile fat arrows to fat arrows, or CoffeeScript’s class to ES2015’s class? See also #3162.

[adam-h]

It's worth noting that browser support is relatively strong already for ES2015 features.

• Chrome and Firefox supports most everything
• MS Edge has strong support under a flag
• Safari 9 has some, but the technology preview supports almost all
• Node 6 (upcoming LTS) supports almost all

I would guess that if CoffeeScript started work on ES2015, by the time it was ready evergreen browsers would support it without transpiling.

source

[MrOutput]

@adam-h that's common knowledge at this point and not worth noting. The idea is that developers need to know if their existing coffeescript needs to be rewritten in native code to leverage emerging technologies or if coffeescript creators will adapt to the standards for their product to stay relevant.

[JimPanic]

What interests me the most: are there plans for coffee to develop any direction (e.g. the redux fork)?

ES6 is just one of those directions it might go, the other ones are equally interesting for me to think about though.

[loveencounterflow]

I must say I'm just as worried about the future of the language as I was enthusiastic when I started to use it years ago. I have advocated many times that in my view, what CS needs to keep developing are 1 optional language features that can be turned on on a per-module or per-function base, similar to "use strict" (NO command lines switches pls!), 2 implemented in a 'modular' (not necessarily in the CommonJS sense) / 'plug-in' fashion, 3rd parties welcome.

[kulicuu]

No need to worry.
CS is maybe the best (on balance over a number of factors including ecosystem) and certainly the most underrated language on the planet right now. Why? 1. npm/node ecosystem, 2. JS (itself an underrated language)(a powerful FPL and flexible object model), 3. Features & syntax: Language features allowing concise code like comprehensions and destructuring assignment (which are now in ES6/7 but originated in CS (in JS world)) world's best syntax (beats both Ruby & Python on sheer concision).

I'm interested to hear what CS can't do, not as against ES/JS (no issue), but as against Clojure & Haskell in terms of FP patterns. e.g. what can you do in Haskell &or Clojure that cannot be done in CS ?

Yet CS is considered an unfortunate mutant. Whereas Clojure has real cachet (deservedly as Lisp dialect, and JVM access to full Java ecosystem), and Haskell is something truly extraordinary, to use CS is to be considered simply pretentious and probably not very smart. It's stupid, but that's fashion, and how I gauge sentiment in Tel Aviv anyways.

And this is the only real downside I can see in CS nowadays: that it's considered pretentious &/or taboo in startup culture, and can therefore be a drag on career, adoption, or whatever. Too bad, but not the fault of the language.

"When ES20 adopts a terse Python/Ruby-like syntax[..]", finally, retrospectively, it will be grokked by the herd that CS actually had been the driving/trailblazing force of ES/JS developments the entire time people had been denigrating it as a loser.

Iow, CS doesn't need to do anything to keep pace with ES6 or ES7, it's already way past it. Exceptions pop up and are dealt with, implementation of generator support comes to mind -- not that I've actually used generators in a real project. On the whole, though, it's game over and CS won, just that community at large won't accept this for years to come.

CS should be the focus of active development attention; kept simple and performant. I wouldn't presume myself to be one to prioritise feature implementation, that's for others. I am going to try to get into contributing some on outstanding issues. Hopefully will have some work completed on that soon.

Btw, are there docs for contributing, running tests etc? I've just pulled a new fork and am looking through the issues... I'd like to have a go at some of these...

I suppose if I had a feature request, it would lean towards implementing anything that would improve FP capabilities. Other than that, maybe namespaces. After years of bowing to the popular sentiment against global variables, I've been using them to great effect in my webapp code to cut down (significantly) on boilerplate code.

[danielbayley]

it's considered pretentious

What's pretentious is pretending that plain vanilla JavaScript isn't a fugly pig of a language and ES6 isn't a thin layer of lipstick on it.

[kulicuu]

Agreed.
Otoh, JS is a powerful and flexible FPL and OOPL. This is what allows me to think and say that maybe CS is the best (on balance) language on the planet.

[danielbayley]

Sure, and it has the best ecosystem. Just the syntax is awful. It's totally fine if people (usually out of habit/coming from C type langs etc…) prefer it but please stop with this meme that CS is dead and we all have to conform to it's poor replacement in ES6. Bracket nazis…

[kulicuu]

Agreed on that.

[mrmowgli]

+1 on what the planned ES6 to CS mappings will be in the future.

I don't think there needs to be much actually done to CS to leverage everything. Looking at the compatibility map gives a nice list of the language features.

Changes would seem to fall into two categories: languages-isms (like the function*(){} vs. yield keyword) and JS keywords. I don't think CS cares whether you use Promises or not for instance.

Really what parts of ES6 can you not currently do in CS?

[ghost]

I prefer CoffeeScript over Python because it's nicer, doesn't have the stupid 'def' keyword that looks ugly and even uglier now with 'async def' in Python 3.5. The package system (npm) is way better and simpler than python's pip.

So there you go. Better syntax, more dynamicness and isn't ugly like vanilla JS or even ES6 ("import redis from 'redis'" -- really?).

+99999 for CoffeeScript. On a side note, will IcedCoffeeScript ever get merged into this repository?

[DomVinyard]

@mrmowgli

Async/Await is a real paradigm shift for the entire language in terms of the cognitive representation of control flow. I think if coffeescript were to nail that (for me that means implicit async if await is detected in the function body), that would go a long way towards feeling 'up to date'.

+1 for best language on the planet.

[carlsmith]

Really what parts of ES6 can you not currently do in CS?

You can't extend ES6 classes. There are other things, but they can be fixed - many have been fixed in forks - but unless someone knows how to make CS and JS classes compatible, we're going to need a breaking change. Otherwise, we will not be able to use certain JS library APIs from CoffeeScript.

If anyone wants to discuss how to prevent CoffeeScript from becoming obsolete, or just to tell us why we're wrong, there's a new repo that you're all welcome to contribute to.

[crisward]

Anyone messed with this https://github.com/decaffeinate/decaffeinate ?
(just noticed the issues section is full of bugs currently, but they are at least pushing in the same direction)

[danielbayley]

There are now at least 3 different repositories focused on this:

• decaffeinate
• decaf
• coffeescript6

See also #4078…

@jashkenas If only efforts could somehow not be duplicated/wasted by bringing them together under the CoffeeScript organisation…

[vendethiel]

related coffeescript6/discuss#3 (comment)

[GeoffreyBooth]

Do we want to link to coffeescript6/discuss from coffeescript.org?

[GeoffreyBooth]

I think the README at https://github.com/coffeescript6/discuss and the comments on coffeescript6/discuss#36 are pretty much what I was looking for in terms of a public statement. I accept that these are “public enough” even if they’re not in this repo or on coffeescript.org, acknowledging the concern of overly presenting our plans to the point of promoting vaporware.