FAQs: es6 roadmap, choosing an implementation, tooling

[SonOfLilit]

I'm doing research prior to adopting Coffeescript for a young startup's codebase. After intensive googling, I found no clear answers but many people asking themselves the same questions, so it may be a good idea to amend the FAQ with answers to these:

• What is the roadmap for ES6 support? When will features be supported? (When ES6 is standard? When it is supported? Never? Per-feature? How is it decided?) What kind of support can be expected? Will it break backwards-compatibility?
• I understand that this implementation is considered best practice and Redux is dead code? Is this correct?
• What is considered best practice tooling for working with Coffeescript? jslint? coffeelint? Anything else different from what you'd use with vanilla JS?

Thanks.

---

A discussion we had today on IRC:

<sonoflilit> Hi
<sonoflilit> I'm considering moving our young startup's codebase from js to CS, and am concerned about future ES6 support
<sonoflilit> Is there a roadmap somewhere that I'm missing?
<sonoflilit> also, is best practice to use CS or CSR?
<apanek> sonoflilit: Regarding ES6, I would say: unconclusive :) https://github.com/jashkenas/coffeescript/issues/3698
<apanek> sonoflilit: Personally, I find CS without classes a lot more comfortable to work with than plain JS in any way. I'm not sure porting all the codebase is necessary though.
<apanek> I'd go with writing new modules in CS as you see fit and porting old modules when you change them - given you want to use CS. It also makes for an easier way back if you plan to not use CS anymore.
<sonoflilit> we're still a small enough codebase that it makes sense to use js2coffee once and get done with it
<sonoflilit> but I'm afraid of the community dying
<sonoflilit> and translating back from CS to js isn't as trivial, because you get code with so many insurance clauses that it's unreadable
<apanek> I can't tell. Since I started my devops job, I didn't really do any client-side work.
<sonoflilit> so this is a one-way decision
<apanek> If you look at the issues of jashkenas/coffeescript, the discussions seem alive.
<sonoflilit> it does indeed
<sonoflilit> is tooling around CS going to remain alive?
<sonoflilit> is it even meaningful, or do you all use exactly the same tools js programmers use?
<sonoflilit> apart from `coffee`, of course
<apanek> I never used special tools.
<apanek> I don't know whether there are any :)
<sonoflilit> e.g. a linter
<apanek> There was a coffee --lint but it was removed in favour of JSHint according to the changelogs.
<apanek> The old coffee --lint command has been removed. It was useful while originally working on the compiler, but has been surpassed by JSHint. You may now use -l to pass literate files in over stdio.
<apanek> ""
<sonoflilit> so this is not best practice? http://www.coffeelint.org/
<apanek> Oh cool :)
* apanek is not up to date
<sonoflilit> gotta say, an almost empty IRC channel is quite concerning
<sonoflilit> or is it me living in the wrong side of the world?
<sonoflilit> 6:32AM in the valley, yup
<apanek> I can't tell. There's not too much going here, but people stop by every now and then to discuss things or ask questions. Most of the project communication is probably on Github.
<apanek> I'd suggest asking those questions on Github as well, you might get more up to date answers and probably also an answer from jashkenas.

[jashkenas]

• 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.
• I don't believe that Redux ever quite reached full compatibility with CoffeeScript, but it's quite close. Both projects are pretty stable, and don't change much.
• Ideally, you don't need any linter to work with CoffeeScript.

Cheers.

[SonOfLilit]

Thanks.

If you can clarify a bit, I'll submit a PR for the FAQ page. Feel free to ignore one or more of the points if you don't have time for this.

Specifically:

• Of course we need a linter, to catch when one of our developers uses an unconventional name, or the wrong amount of whitespace, etc'. Which is recommended by the community? (everyone, feel free to pitch in)
• I understand that Redux is unmaintained right now? Did anyone take over?
• A non-binding statement of intentions re: support of different ES6 features (probably as a table) will be very helpful in convincing CTOs to adopt Coffeescript. I know generators are already supported, and I see binary literals are too, but what's the latest word about...
  • ES6 classes (is there a use case for this? "Not needed, because CS classes are fine for all uses" could be a good answer if that's correct)
  • modules
  • let, const (I assume the answer would be "no, never"?)
  • an ES6 emitter for features that seem to already have syntax support, just for performance reasons (I can't see why this is needed, but an official position is useful when making the case to your CTO, or in my case, to myself as CTO): default parameters, fat arrows, etc'
  • tail-call safety, i.e. emit JS that would get tail-call optimized wherever applicable

[jashkenas]

• If you want one, CoffeeLint is the only CoffeeScript linter that I'm aware of.
• Your Redux question can be answered by looking at the commiters: https://github.com/michaelficarra/CoffeeScriptRedux/graphs/contributors It looks like your answer is: "no".
• Classes: CS classes are staying the same for the moment, to preserve compatibility. We might want to switch to compile to native classes in the future, but there are problems with differences in semantics. Executable class bodies is just one example of a huge feature that might be lost. In short — not changing soon.
• Modules don't yet exist in JS implementations, as far as I'm aware.
• Const, never. Let, maybe someday, but there's not much (anything?) to be gained. Remember, CoffeeScript doesn't even have var.
• Emit ES6 -- yes, once it's supported across the board. Arrow function don't exist in IE11, for example. Destructuring doesn't even exist in IE edge.
• Tail-call optimization doesn't yet exist in shipping JS engines.

[GeoffreyBooth]

I’m tired of reading how CoffeeScript is obsolete now that ES2015 is here to save us. I use CoffeeScript for the syntax, not the features that ES2015 has been busy catching up to, and the day I stop using CoffeeScript will be the day it’s pried out of my cold dead curly braces.

I am worried, though, that as time goes on and more people learn ES2015, I’ll have a harder time convincing teams and bosses to use CoffeeScript. There’s currently barely a mention of ES2015 in the readme or on coffeescript.org, and too many people assume that the project is dead and will slip into obsolescence as ES2015 gets more widely adopted. At the very least, there needs to be a prominent section in the readme and at coffeescript.org explaining CoffeeScript’s relation to ES2015, especially why CoffeeScript is still relevant today and will continue to be relevant when ES2016 and ES2017 and so on arrive. What I tell skeptics is that I expect CoffeeScript to continue to mature along with JavaScript, and when new versions of JavaScript reach wide adoption CoffeeScript will simply compile down to whatever the new target is, when there is a performance or readability benefit to doing so. I tell people that they should think of CoffeeScript as primarily an alternate syntax for JavaScript, one that prevents stupid bugs through things like significant whitespace and the ? operator, and that this much-improved syntax will never get obsolete so long as ES* maintains backward compatibility.

I see defenses of CoffeeScript in this new ES2015 era that go along the lines of, well currently both ES2015 and CoffeeScript need to be transpiled down to ES5 or ES3, and that will be the case for many years, so what’s the difference? And by the time Microsoft Edge is the oldest IE we need to support, CoffeeScript will (presumably) compile down to ES2015, so there’s nothing to worry about. But this neglects two moderately large use cases where big chunks of ES2015 are usable today, without transpiling, thanks to the growing support already present in Chrome:

• Internal web apps where we know that the user will be using Chrome
• Server-side code running under Node 4+

I don’t know what, if any, performance benefits anyone gets from letting Node 4 use native ES2015 features rather than the compiled-to-ES5 replacements, but presumably someone somewhere will claim that they must have ES2015-native code running in their Node app, or their app will suffer mightily, and therefore the app can’t be coded in CoffeeScript. Or ditto for a private Chrome-only app. And the thing is, they might be right. At the very least, it will be easier to debug such apps if the fat arrow compiles to a fat arrow, etc.

So besides updating the docs, which I feel like is the bare minimum response that ES2015 requires, we should perhaps discuss some future CoffeeScript that compiles at least some features to ES2015. Perhaps this could be a non-default feature enabled by argument, e.g. --target=es2015 say for when we’re compiling server-side code. A lot of work has been done in this pull request for CoffeeScriptRedux; maybe it can serve as a starting point? And as for updating the docs, I second @SonOfLilit and would be happy to start or contribute to a pull request explaining CoffeeScript’s post-ES2015 roadmap, if @jashkenas or another project maintainer would be so kind as to share some thoughts as to where they generally see CoffeeScript’s way forward.

[carlsmith]

I just started work on a site generator type thing. The tool is V8 only, so thought I'd be lazy and give ES6 a go. I had about 30 lines of JS written when I switched to CoffeeScript. It was like switching from Klingon to French.

[vendethiel]

(as a french one, I can guarantee we still have some pretty weird rules :P)

[carlmathisen]

Looks like ES6 support might be happening, jashkenas has offered commit access to Decaf author (Decaf is CoffeeScript that transpiles to ES6).

https://github.com/juliankrispel/decaf/issues/14

[jashkenas]

Hey folks, @juliankrispel.

Julian emailed me back, but I'll respond here, so as to leave it in public. I just thought that since there's rightly a lot of interest in having CoffeeScript target ES6 instead of ES3, and Julian was actually doing something about it, and he attracted the interest of known solid contributors like @lydell and @eventualbuddha, it might have a higher chance of success getting done in a branch over here with a little more attention available to it.

That said, if anyone — new contributors or old — wants to experiment or play around in an "es6" branch, go nuts. I'd imagine you'd start behind a coffee --compile --es6 flag, and see how things shake out.

[juliankrispel]

That'd be a huge boost to the project @jashkenaz!

Thanks!

What do I do now? :)

Julian Krispel-Samsel
rainforestqa.com
goodafternoon.co

On Jan 31, 2016, at 12:13, Jeremy Ashkenas notifications@github.com wrote:

Hey folks, @juliankrispel.

Julian emailed me back, but I'll respond here, so as to leave it in public. I just thought that since there's rightly a lot of interest in having CoffeeScript target ES6 instead of ES3, and Julian was actually doing something about it, and he attracted the interest of known solid contributors like @lydell and @eventualbuddha, it might have a higher chance of success getting done in a branch over here with a little more attention available to it.

That said, if anyone — new contributors or old — wants to experiment or play around in an "es6" branch, go nuts. I'd imagine you'd start behind a coffee --compile --es6 flag, and see how things shake out.

—
Reply to this email directly or view it on GitHub.

[flying-sheep]

What do I do now? :)

hmm, i’d say:

1. get @eventualbuddha’s expertise on board.

   decaffeinate is more mature than decaf, so i bet he’s learned some lessions that could be beneficial to know.

2. change the lexer/grammar so that e.g. template literals are first class literals in the AST

3. make the output configurable. current design is based on the node method Base::compile() which means: “render me to ES3”. the node classes need to be decoupled from the output format.

   dunno how to do backwards compat here though. most Base methods are coupled with the ES3 output. we need to know how much we can throw out of the node classes. ideally we remove everything that varies with output and the helpers built to do the ES3 output, and keep the node manipulating functions (e.g. to find and traverse children). finally we add a renderer optional argument to compile that handles all the compiling/rendering. the default (ES3)-renderer contains all the code currently in each node’s compileNode method.

   then it’s just a matter of adding a second renderer which can be passed to some node’s compile method and handles conversion to ES6.

[GeoffreyBooth]

If I could just offer one suggestion: keep in mind the destinations for this generated code. In broad terms, they are:

1. Frameworks like Meteor and Ember that require you to use ES2015 modules.
2. Server-side code running in Node 5+, which natively supports most of ES2015’s features.
3. Client-side code running in Chrome-latest or other very modern browsers, which natively support many of ES2015’s features.

I suppose the easiest approach for now is to set a target of ES2015, and let Babel handle converting that down to ES5 for all three destinations. It would be nice, though, if we could somehow get ES2015 or mostly-ES2015 code for cases 2 and 3, so that the code we debug with is closer to the original CoffeeScript (i.e. with fat arrows preserved, etc.). Maybe that’s a challenge for Babel rather than CoffeeScript, assuming that Babel will need to be part of the pipeline until ES2015 support is complete in Node and in whatever browsers your app is designed to support.

At the very least we should probably call the flag --es2015 or --target=es2015 so that when ES2016 is finalized and we eventually support compiling to ES2016, it’s possible to control whether we’re compiling to ES2015 or ES2016 (and beyond). If we want to go all out, we could provide a way to set a configuration, telling the compiler exactly which features to compile in the ES2015 way and which ones to not—for example, to configure fat arrows to stay fat arrows, ES2015-style, while everything else gets converted down to ES5. Such granular configuration would mean that we wouldn’t need Babel in the pipeline for server-side code or for Chrome-only apps, as we could configure the CoffeeScript compiler to generate code that uses only the ES2015 features that Node or Chrome support while compiling down to ES5 for the rest.