
Replace CoffeeScript with ES6 - Croaky
http://robots.thoughtbot.com/replace-coffeescript-with-es6
======
mrinterweb
The reason that I like CoffeeScript is that it removes, what I consider, the
unnecessary boilerplate of JavaScript and replaces it with a shorthand
equivalent and good conventions. I feel that CoffeeScript is better at
representing the intent of JS than JS. I can visually sift through
CoffeeScript and understand the code much quicker than normal JavaScript,
which in my opinion leads to more maintainable code. I'm not certain what is
appealing about reading and writing more code for the same result.

Many people don't like that CS needs to be compiled. I don't see this as an
issue since pretty much every application I work on these days is concatenated
and uglified. So adding a JS compiler is already part of most JS application's
build process. 6to5 is being compiled to ES5 anyway. Also, if you include in
your build pipeline a source mapper, debugging is not a problem.

~~~
qwer
My biggest problem is definitely the source maps. It took me forever to get
them to "work" and while the stack traces are mostly correct, they're often
off by a line number or two. This makes debugging ridiculously hard when the
line numbers are just "close".

I know this might not sound like a big deal in the grand scheme of things, but
I also don't think CoffeeScript really improves on js all _that_ much, so the
annoyances of source maps are just not worth it to me personally.

~~~
jashkenas
Have you tried them at all recently? If a source map is off by a line, that's
a bug that should be reported and fixed pronto.

------
jashkenas
Folks, this was always part of the plan ;)

CoffeeScript is a fun little experiment in what's possible when you take
JavaScript semantics and try to boil down the user interface to a minimalist
surface. But JavaScript will always keep on rolling onwards — and to the
extent that future versions of JavaScript take any minor inspiration or
reference or overlap with things that CoffeeScript already does, the more the
better.

For example, see this talk from four (!) years ago:
[https://www.youtube.com/watch?v=QTj6Q_zV1yg](https://www.youtube.com/watch?v=QTj6Q_zV1yg)

There's more than one way to skin the JavaScript cat.

In other news, CoffeeScript 1.9.0 came out yesterday — with support for ES6
generator functions. A-la Python, in CoffeeScript, a generator is simply a
function that "yield"s.

~~~
ffn
Thank you jashkenas-sama, please keep the good works with coffee (and
underscore, backbone, etc.). We Rubyists and Pythonians are all (well, at
least I am) eternally grateful to you for having delivered us from the evils
of brackets, parenthesis, if !condition, and that thing were we had to
firstArg = [].prototype.slice(arguments, 1) in every function where we needed
splats.

------
addisonj
I give credit to CoffeeScript with really helping to push the ES specs forward
and think it helped introduce more people to JS and grow the ecosystem. Heck,
I used it for a year, liked it, and had it change some of my approaches to
writing JS.

That said, I hope it slowly fades into the background as more people go back
to vanilla ES6 or go with something more powerful such as TypeScript (or
Flux). With the progress around es6 and es7, gradual typing, macros, and other
tooling around the language, I think CoffeeScript risks becoming a drag on
getting people to learn modern JS and instead sticking with a language that
has a lot of ambiguous constructions and fewer and fewer advantages over JS.

~~~
briandear
I sure hope you're wrong. The unnecessary clutter of plain JS is just painful
to look at. I can't remember how many times I've looked over a 40 line block
of JS searching for a missing. When there are many )} )}; } ; } ; } -- it is
just downright frustrating to be be wasting any time on what is effectively
irrelevant syntax. With CS, it's indent and be done with it. It's like SASS
vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone
would prefer more to less. To take Haml as an example:

.my-div %h1 Some Text \- some_ruby_code

vs the ERB of

<div class="my-div> <%h1> Some Text </h1> <% some_ruby_code %> </div>

~~~
tragic
> "With CS, it's indent and be done with it"

As others have said, it's all fun and games until two people edit the same
source file, one of whom has the dangerously incorrect opinion that tabs are
better than spaces :-)

I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a
tradeoff: you gain in terms of redundancy, true, but there's an additional
human overhead of making sure everyone's got their editors set up correctly.
The larger the team, and a fortiori the number of teams, the bigger that
overhead is. Smacking people about the head with PEP8 goes quite close to
solving the problem in the Python world, but CS's Rubyish commitment to
TIMTOWTDI militates against that.

"It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure
out why anyone would prefer more to less."

Because HTML and CSS, despite their verbosity, are _linguae francae_. A CSS
file is valid SCSS _by definition_ \- a less technical prototyper person can
give you their code (perhaps even generated code from some wysiwig
monstrosity) and you can refactor over it to remove redundancy, enforce
conventions etc using the special SASS sauce. The SASS syntax does not.

A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible'
with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very,
very ugly and a dreadful idea, and I'm not sure if it's possible to mix the
two in similar template languages (Jade etc).

Point is: there is a human factor involved in picking shinier toys. I like
HAML/Jade type templates, and Coffeescript for that matter, but I am far more
comfortable using them on small teams or solo projects.

~~~
jessaustin
_...two people edit the same source file, one of whom has the dangerously
incorrect opinion that tabs are better than spaces_

Commit hooks will help you:

[http://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks](http://git-
scm.com/book/en/v2/Customizing-Git-Git-Hooks)

The bigger your team, the more you need them.

~~~
mistercow
For open source projects, that's less of an option, but regardless, an
individual's opinions about tabs and spaces are moot when working on a multi-
dev project. You follow the project's conventions, or your changes don't get
merged.

~~~
jessaustin
Yes it is frustrating that git doesn't automatically transfer hooks to cloned
repos. I _guess_ I understand the standard explanation of "git clone" never
running arbitrary code on one's machine (although in a sense that is git's
purpose), but it does reduce the use of client-side hooks in open projects.

------
picardo
CoffeeScript syntax is better and cleaner than the ES6 syntax. It's a fun
language, and I've been using it everyday since it came out. On small
projects, it's top-notch.

But the future of CoffeeScript is bleak because many software designers are
beginning to understand the value of type systems, e.g. TypeScript and Flow,
for building maintainable Javascript code bases, and this means CoffeeScript
is out of the picture for good because its long term design goal is to remain
a minimalistic language, and doesn't intend to support these ideas. There have
been attempts[0] to fork it to add a legitimate type system to it so it can
scale, but they have faltered. Aside from that, the way CS deals with variable
shadowing[1] makes it risky to use in large codebases.

So when ES6 syntax is tolerable and stable, I will pack my bags and move over
to the ES6 land with great regret. I wish I could stay in CS land for longer,
but you have to put away childish things eventually.

\------------

[0] [https://www.npmjs.com/package/typed-coffee-
script](https://www.npmjs.com/package/typed-coffee-script)

[1] [http://stackoverflow.com/questions/15223430/why-is-
coffeescr...](http://stackoverflow.com/questions/15223430/why-is-coffeescript-
of-the-opinion-that-shadowing-is-a-bad-idea)

~~~
atrilumen
Speaking of putting away childish things (like effect-ridden, imperative
spaghetti code), PureScript is my new CoffeeScript.

[http://purescript.org](http://purescript.org)

~~~
wcbeard10
Have you found a good framework that purescript supports in the vein of
Angular or React? I had a look a while back but the support was a bit spotty
for me.

~~~
purescript
Maybe [https://github.com/paf31/purescript-
thermite](https://github.com/paf31/purescript-thermite) ...

------
zerker2000

      it solves a lot of the problems that CoffeeScript is trying to solve without drastic syntax changes.
    

I cannot speak to authorial intent, but for me the majority of the problems
CoffeeScript(and moreso LiveScript) solves _are_ syntax ones.

~~~
acjohnson55
ES6 solves many of those same problems that required overly verbose or awkward
ES5 syntax. Things like basic this-preserving closures, collection extraction,
and so forth. Same problems, similar but less radical solution in ES6 vs. CS

------
abecedarius
ES6 has 'let', while CoffeeScript has an '=' that might be local binding and
might be nonlocal assignment, depending on what's in scope. I wanted to like
CS, but I don't want to live with that one decision.

~~~
batiste
The scoping issues with CoffeeScript is what triggered me creating this little
language: [http://batiste.info/CokeScript/](http://batiste.info/CokeScript/)
At this point it still a bit of a joke, but if I have more time to work on it
I could take to a usable state.

------
albertoleal
Should be retitled 'Replace CoffeeScript with 6to5'.

You can start using transforms that provide features other than ES6:
[https://6to5.org/docs/usage/transformers/](https://6to5.org/docs/usage/transformers/)

------
sgslo
Yes and no. Although we get some fantastic features, one of the most critical-
the ability to neglect parens and curly braces- is lost in es6. I'm working on
an es6 project right now and still prefer coffeescript.

~~~
recursive
For functions of single arguments, you parameter list parens are optional.

But it's not an objective fact that coffeescript's syntax is better. I prefer
ES6. And even if you prefer coffeescript, it seems strange to claim that the
_most_ critical feature is purely aesthetic.

~~~
briandear
Assuming it's all ultimately JS, the aesthetic side is a big deal. It results
in an easier time understanding and being able to debug the code, which is a
huge, perhaps underestimated win.

------
slimetree
What CoffeeScript did was lodge the idea in people's heads that JavaScript can
be treated as an assembly language to compile higher-level languages into.
I'll bet many programmers' attitudes toward ES6 are: someone will write a
compiler for my language, and I'll just use that.

It seems better to treat JavaScript as admittedly not being the most powerful
language in the world, and to treat the standard as a kind of RFC that only
compiler writers have to think about. For most programmers it works to just
use CoffeeScript (or Lisp or anything) without worrying about standards, just
as JavaScript programmers don't need to worry about how their processor works.

~~~
marcosdumay
In fact, maybe Javascript is too powerfull. It would be interesting to get a
stack machine emulation in the browser, with an standard set of
libraries/tools for native access to the DOM and emulators for most
interpreted languages out there.

Kind of a Java plugin that runs on web, instead of just tunneling through it.

------
sebastianmck
There's also decaffeinate[1] that converts CoffeeScript to ES6.

1\.
[https://github.com/eventualbuddha/decaffeinate](https://github.com/eventualbuddha/decaffeinate)

------
meowface
Why not both? This makes a good argument for ES6, but CoffeeScript's
fundamental changes to syntax are just preferred by some.

~~~
recursive
Because one day ES6 will run in browsers without a build step.

~~~
matthewmacleod
I'm not sure that's a convincing argument – you will in almost every
conceivable case have a build pipeline in place anyway, so there's not really
a cost there.

~~~
Touche
I don't set up a "build pipeline" until I'm sure the app is going to deployed
to a production environment. Why would I set up a build for what is
essentially a fiddle, or if I'm just experimenting? The now-common workflow
where people write build scripts at the start of a new project is just bizarre
to me.

~~~
iopq
Sure, and why do people use C anyway? You can write binary directly without
any kind of make utility.

~~~
recursive
Probably because machine code is not very human comprehensible.

~~~
iopq
Neither is minimized JavaScript

------
lucaspiller
I wonder if ES6+ is going to become the new HTML5 - all these great features
but no hope of proper browser support for years. I had no idea ES7 was also in
development, so it seems like browsers are always going to be playing catchup.
The comments on an article here the other day said people aren't upgrading
tablets as often as phones. I can see a lot of tablets being stuck on ES5,
that people don't want to upgrade, as they can still browse the Facebooks and
Googles fine.

~~~
mbrubeck
Firefox and IE11 already natively implement a majority of new ES6 features,
and Chrome is getting there:

[http://kangax.github.io/compat-table/es6/](http://kangax.github.io/compat-
table/es6/)

The main laggard for now is Safari/WebKit.

~~~
TheHippo
Current stable browser versions:

FF 35: 60% Chrome 40: 35% Safari 8/Mobile: 22% IE11: 21%

~~~
mbrubeck
Oops, yeah. I wrote "IE11" but I meant "IE TP".

The dev versions of IE/Firefox/Chrome/WebKit are up to 70%/69%/48%/28%
respectively.

------
pjwal
The "all or nothing" with CS has always been a non starter for me. I find it
really hard to believe that it is possible for a team of more than 2 or 3 to
remain happy with a choice to use it after any extended period of time. If
you're out there though, I would love to hear from you!

And yes, this can be said for almost any tool choice, but my spidey sense
tells me the half life for CS is about that of something like Jira.

~~~
elros
I don't know what you consider an extended period of time, but I've been
writing CoffeeScript full time for 2 years now, and it's been like that at my
day job (moviepilot.com) for at least 2 more before I came. Couldn't be
happier!

Team size varies between 8 to 15 people, roughly.

------
msutherl
Is there a preprocessor/transpiler that lets you write vanilla ES6 but just
without brackets, semi-colons, etc. like CoffeeScript?

~~~
mattdesl
Semicolons are already optional in JS. Automatic semi colon insertion (ASI)
has a clear set of rules that are pretty easy to remember.

[http://mattdesl.svbtle.com/to-semicolon-or-
not](http://mattdesl.svbtle.com/to-semicolon-or-not)

~~~
SomeCallMeTim
But ASI is controversial, because of the bugs that can be caused by it. (See
"JavaScript, the Good Parts"). I make our devs (myself include) use semicolons
with jshint, because I believe it's too easy to screw up.

~~~
Already__Taken
After reading the linked [Isaacs]([http://blog.izs.me/post/2353458699/an-open-
letter-to-javascr...](http://blog.izs.me/post/2353458699/an-open-letter-to-
javascript-leaders-regarding)) post it made me realise a bit more about the
language. I don't think I'd agree its easy to screw up. Its as easy as
accidentally using global variables.

------
mikeryan
Note that self = this is kind of a legacy hack for binding 'this'.

ES5 has Function.bind

[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)

~~~
peter_l_downs
It can also be nice when you're writing instance methods on a prototype. for
instance:

    
    
        var Person = function(name) {
          var self = this;
          self.name = name
        };
    
        Person.prototype = new function() {
          var prototype = this;
    
          prototype.sayHello = function() {
            var self = this;
            return "Hello\n\n-- " + self.name;
          };
        };
    
        var me = new Person('Peter');
        console.log(me.sayHello());
    

Obviously that's a pretty contrived example but it illustrates the idea. It
makes it really clear exactly what "this" means at different points in your
code. As a bonus, if I had to reference the current context inside of a
prototype method, "this" is now available.

~~~
bshimmin
I don't like `var self` at all and I find there are vanishingly few places
where you can't just bind a function appropriately, but one important thing to
note, if you do go down this route, is that `self` is an alias for the
`window` object, so if you happen to miss out that `var self` assignment at
some point, you may get unexpected results.

On that basis, if you must do this, I would suggest `var _this`, `var scope`
(though that would probably be confusing if you had the misfortune to be using
Angular), `var me` (unless you happen to find anthropomorphism distasteful)
or... well, anything other than `var self`, really.

~~~
peter_l_downs
Interesting, I never knew that `self === window` – thanks for bringing that
up. I'm not particularly attached to the name, just wanted to show an example
where assigning `this` to some local variable is useful.

------
risent
ES6 make JavaScript more powerful, but CoffeeScript is really elegant in a
Python developer's scope.

------
kin
I had fun with CoffeeScript but my projects definitely had its frustrations.
CS allowed me to write some pretty damn ambiguous code.

Also when working with external libraries and dependencies, I found myself
resorting to trial and error figuring out the correct syntax because nearly
all documentation is written in JS and not CS.

------
shittyanalogy
Mmmm _without drastic syntax changes_?

Classes:

    
    
        There is no semicolon after the function name
        The function keyword is omitted
        There are no commas after each definition
    

Interpolation:

    
    
        `${1 + 1}` <- why not just # like everyone else?
    

Multi line strings:

    
    
         ` Now we have a 3rd
           string delimiter`
    

Fat arrow:

    
    
        $("button").on("click", () => { 
          // really? hanging parens? no function keyword?
        });
    

Destructuring:

    
    
        var [first, , last] = [1, 2, 3]
        // thats a var to assign vals inside an array
        // and just two commas touching to ignore a value
    
    

The whole post is about drastic syntax changes. The brackets are optional in
coffeescript.

Besides coffeescript is just a tool.

~~~
ahoge
> _why not just # like everyone else?_

You mean like CS? '#' actually isn't a very popular choice for this.

[http://en.wikipedia.org/wiki/String_interpolation](http://en.wikipedia.org/wiki/String_interpolation)

~~~
pmontra
Coffeescript's origin is in the Ruby community. The first interpreter was also
written in Ruby. Ruby interpolates strings with #{} so that was a logical
choice for Coffeescript.

The significant spaces thing was ironic given that Python is kind of the
biggest competitor of Ruby (×) in the modern scripting languages space.
Personally it's the main reason I'm not using CS (or Python or HAML or Slim),
transpiling is number 2.

(×) kind of because Ruby is probably more successful in web development but
less anywhere else.

~~~
tiglionabbit
I don't understand why significant indentation is a bad thing. It's easier to
read indentation than it is to try and match brackets in your head.

The only times it bites me is when I accidentally mix spaces and tabs in the
same block, which could use a warning.

~~~
pmontra
I'm more into Ruby than in JavaScript even if I have 10 years of Ruby vs 20 of
JS on my shoulders. In my experience Python is always easier to read than JS.
It's easier than Ruby for the part that spares me from a silly looking
sequence of end end end at the end of some nested block (but that : before a
new indentation level looks silly too.)

The syntax of both Ruby and Python beat squarely any C-like language, even if
Python looks strange to me. Perhaps is the mix of objects and functions that
makes it look a little C-ish, or the many __name__ one has to write in same
cases. Anyway...

I would do without JavaScript's {} () and ; or Ruby's end (which bugged me a
lot 10 years ago) but unfortunately that easier syntax is offset by the too
many times it came biting me with nasty bugs after I cut and pasted code
around during refactoring. Or having to take really care of how many spaces
I'm deleting to match the indentation level I must reach. The editor can't
autoindent all the file for me. It's bad enough when I'm working in YAML files
(the format of Rails's i18n db, another ironic choice) and I don't want to
deal with it in all my codebase.

So in my experience significant indentation is evil because as a matter of
fact is making me less productive. Lot's of people share the same feeling,
lots of people are happy with that. No problem, there are so many choices that
we can always pick what's best for us.

PS: I just thought that maybe an editor could autohide Ruby's end (or color it
almost away) and still be able to autoindent code. Maybe I'll try to tell
emacs to color end in dark blue (black background) and see what happens to
code readability.

------
someguy1233
I'm surprised nobody has mentioned TypeScript. I've been using it in one of my
projects recently (WebStorm even has a file watcher that works with very
little set up on my Macbook).

TypeScript is pretty good at giving you a taste of ES6, it brings in a lot of
features from ES6, such as the new classes, default arguments, generics, as
well as a few of it's own features (interfaces, optional static type
checking).

They ship it as a node module, so you can just "npm install -g typescript" and
it's ready to go. As much as I dislike Microsoft, Typescript is something that
seems to work well, and unlike Coffeescript, I can quite happily paste in
standard Javascript code (even most ES6 code) and it won't break my source.

------
nothrabannosir
If you're going to use something with JS's syntax, at least take Typescript or
Flow for some compile time checks (optional types, function arity, variable
names, &c).

~~~
grandalf
Is there anything like flow for Coffeescript?

------
jongraehl
Braces combined w/ something like clang-format or gofmt are clearly better.
Perhaps a really advanced editor (that most people don't use) could offer a
similar experience for braceless (sig. indent) languages.

Short braceless code typesets beautifully, but you can probably get a similar
effect w/ an appropriate 'braces highlight at lower contrast when autoindented
as expected'.

------
rtfeldman
The body of the post doesn't support the title's recommendation. Each section
shows how ES6 either has an equivalent feature to CoffeeScript, or almost
does; in other words, it is approaching feature parity.

To replace one tool with another, you need a compelling reason...and "it's
almost at feature parity" is not that.

------
mhd
First time I heard of sprockets (weird, being German). How _many_ JS build
tools are there out now? And is none of it deprecated/abandoned?

Other than that, the braces/indentation issue alone will keep people with CS.
Can its compiler emit ES6, by the way?

~~~
bshimmin
Sprockets is part of the Rails asset pipeline - it's not used much outside of
the Rails world.

------
amelius
Minimizing javascript code using a minimizer currently cannot be done well in
a guaranteed way, because the minimizer must make too many assumptions.
Therefore, I think javascript is too dynamic for a web-language.

Unfortunately, they didn't solve this with ES6.

------
mkolodny
For those using browserify, you can use es6ify to compile ES6 to ES5 on the
fly.

[https://github.com/thlorenz/es6ify](https://github.com/thlorenz/es6ify)

~~~
sebastianmck
Alternatively there's 6to5ify[1]

1\. [https://github.com/6to5/6to5ify](https://github.com/6to5/6to5ify)

------
ziahamza
The biggest reason why I still dont use coffeescript is that most compile
javascript tooling doesnt work. I cant use types from TypeScript, or use JSX
extentions with coffeescript.

~~~
tiglionabbit
You can use coffee-script with JSX. I'm using cjsx-loader with webpack, and
there's also a stand-alone cjsx compiler.

[https://github.com/jsdf/coffee-react](https://github.com/jsdf/coffee-react)

[https://github.com/KyleAMathews/cjsx-
loader](https://github.com/KyleAMathews/cjsx-loader)

------
tiglionabbit
CoffeeScript compiles down to ES3, which means it's compatible with Old IE.
The ES6 compilers can only compile down to ES5.

~~~
acjohnson55
That's not necessarily true. Many of the features can be made ES3 compatible.
Of course knowing which ones are exactly isn't always straightforward.

------
quadratini
Coffeescript is pretty damn ugly. For god sakes can people please use
parenthesis when calling functions with arguments?

~~~
briandear
Why add unnecessary clutter?

~~~
Gurkenmaster
Lisp programmers would love to disagree

~~~
Guthur
Parenthesis are not unnecessary in Lisp they're an essential delimiter in
defining an s-expression's structure (does not need to be parenthesis but some
token is required).

But for me that one bit of syntax is a lot less that the multitude required
for many languages.

For something even more syntactically minimal there is Forth.

------
scotty79
There is very few features of ES6 that are not syntax sugar.

Those features will be (or already are) ported to CoffeeScript.

And the CoffeeScript sugar is just tastier.

ES6 syntax is kind of CoffeeScript for people who hate meaningful
indentination and it's quite decent for that purpose.

~~~
M2Ys4U
> There is very few features of ES6 that are not syntax sugar.

(Weak)Map, (Weak)Set, Symbol, Generators, Promises, Modules, Proxies... these
aren't sugar.

~~~
scotty79
So generator, weak references and proxies.

Promises, modules we already had. Native implementation doesn't provide new
functionality, just picks winners.

I'm really excited by generators and proxies but those are available in latest
version of CoffeeScript already.

------
gankgu
Good

