Add ES6 transpiler

[taboularasa]

Should we default to coffeescript still? At some point we should start defaulting to ECMAScript 6, is that time now or still wait?

[patbenatar]

I'm in favor of embracing ECMA 6 with a transpiler.

Looping in @jdwolk @pgdaniel @wykhuh @mikehmorrissey @nrswolf @lexi-lambda @cltatman

[jdwolk]

:thumbsup: es6, think it's ready for a spin

[lexi-lambda]

:+1: Transpilers are pretty solid now.

[cltatman]

getting space-age in here :+1:

[wykhuh]

Since I asked about es6 transpiler when I was hired :+1:

FYI, es6 was formally approved yesterday.

[patbenatar]

@taboularasa the only thing we would really do in suspenders for this would be to add sprockets-es6 to the Gemfile... Not a lot of up-front effort to try this out on a project and if we like it / it works (the readme for that gem says "experimental"), standardize on it and drop into suspenders. Thoughts?

[pgdaniel]

[lexi-lambda]

I did a bunch of ES6 research this past weekend, and my preliminary conclusion is that we don't need it. I think the best point of reference to understand what is/isn't supported is probably this page from Babel itself.

The thing is, not all ES6 features can be polyfilled—some need direct browser support—and basically all of the ones that can already exist in CoffeeScript.

Static syntax extensions

• Arrows — in CoffeeScript, plus we get -> which is more consistent with =>
• Classes — in CoffeeScript
• Enhanced Object Literals — in CoffeeScript
• Template Strings — in CoffeeScript
• Destructuring — in CoffeeScript
• Default params and Splats — in CoffeeScript
• Let + Const — partially in CoffeeScript: CS vars are block-scoped, but it doesn't have const

Can be polyfilled

• Iterators + For..Of — partially in CoffeeScript: CS has better iterators but they aren't generic; it does have comprehensions, which ES6 does not
• Generators — in CoffeeScript
• Modules — NOT in CoffeeScript, though it's disabled by default in Babel, and you can easily use any module system you want with CS, you just don't get dedicated syntax
• Map + Set + WeakMap + WeakSet — NOT in CoffeeScript
• Symbols — NOT in CoffeeScript
• Promises — NOT in CoffeeScript
• Reflect API — NOT in CoffeeScript

Cannot be polyfilled or can only be partially polyfilled

• Proxies — Really cool but probably useless for us, anyway (libraries will use them).
• Tail calls — Ditto.

Most of the things Babel gets us that CoffeeScript does not are just libraries. Maps/sets, symbols, promises, and reflection are all just plain JS libs. We could probably just drop in the Babel polyfill for those features and keep on using CoffeeScript.

As for the syntax, CoffeeScript is still a big win. ES6 combines old JS syntax like function () { ... } with new syntax like => and classes. They don't always mix. Do we start choosing fat arrows over the verbose function syntax just for ease of use? That seems like a bad pattern.

I say we keep CoffeeScript, but maybe we should look into using the Babel polyfill with it. :coffee:

[patbenatar]

@lexi-lambda Thanks for the research and write-up! I agree with your assessment that we're not looking at any immediate gains from making a switch to ES6 from CoffeeScript. As you mentioned, many of the libs we've already been working with in one way or another via 3rd party dependencies. My only contrary argument is that a switch to ES6 would put us in a future-friendly position — as ES6 becomes adopted by the browsers our projects are targeting, we could easily switch to using it natively by removing the transpiler.

[lexi-lambda]

Ideally, yes. However, all of the aforementioned library polyfills would still get the benefit of native adoption whether we use ES6 or CoffeeScript as our source language. Proxies fall under the same umbrella: we'll get to use them in CoffeeScript once they're added natively. The only ES6-specific features we won't get are const and tail calls, and CoffeeScript might even add those, too.

To me, that seems like more or less zero gain for a non-trivial loss. Here are things CoffeeScript gets us now that ES6 doesn't have and never will.

• Uniform function syntax (-> and =>)
• Everything-is-an-expression flexibility
• Array slicing syntax
• Better switch
• Syntactic consistency across our stack (mostly—obviously CS is not Ruby, but it's closer)
• List comprehensions (though it seems Babel has its own non-standard extension based on the ES7 proposal, so perhaps this point is moot)

So I guess my real question is: what could we be gaining by switching to ES6, even just theoretically or down the road? In the list of features I included above, I didn't leave much out. The spec is here and it's finalized, and you can see for yourself that most of the wins for JS beyond the purely syntactic-sugar level are libraries. Even if CoffeeScript stays as-is until ES7, it's still on par with ES6's spec, and there's no reason to believe it won't continue to evolve as well to take advantage of new developments.

I'm willing to admit I'm biased. I love the way CoffeeScript lets me write more functional JavaScript without the syntactic noise. That said, I think it's still a winner from a more objective standpoint.

[taboularasa]

:+1: to @lexi-lambda I was under a false impression of what babel I didn't realize that it's only most of es6 that's supported currently and practically speaking we don't gain much by switching just for the syntax

[patbenatar]

@lexi-lambda @taboularasa I'm also a CS fan at my core — although sometimes the masochist in me enjoys the JavaScript syntax... :grimacing:

A minor concern: it adds another build tool to your pipeline.. not a concern on Rails projects, though.

[taboularasa]

@patbenatar ya that doesn't count in this case since we're talking rails only

[lexi-lambda]

...plus Babel requires a build tool in the pipeline, anyway, so it's still not plain JS for now.

[taboularasa]

And masochism doesn't count either because most people don't like that (I think)

[patbenatar]

Whatever we decide here should go across the board (at least for the majority of projects, barring special circumstances)—no reason to be supporting multiple flavors of JS.

@philosophie/devs All, please take a look at @lexi-lambda's research and report above and chime in on the JS vs CS discussion — particularly if you have a strong preference either way.