

Why I Don't Use CoffeeScript - jashkenas
http://oscargodson.com/posts/why-i-dont-use-coffeescript.html

======
jenius
This is straight up misinformed. I see posts like this almost every day, and
the point of every single one of them is "I am already familiar with
javascript, and I'm not familiar with coffeescript, so I HATE IT."

It's very clear that you have not used coffeescript much, you just checked it
out, glossed over a few features, tried to write something, were doing poorly
because you didn't know it well, and said "well fuck it, I'm going to write an
angry rant about this".

Let's break your post down to sections. Syntax first. Most people like the
syntax. It's much easier to read for me and other developers, personally. If
you don't like it, nobody's forcing you to use it.

Your analysis of 'wart removal' is misinformed too. Coffeescript is
essentially a collection of helper functions for things we commonly need to do
(as are many programming languages - for example, ruby, which a nicer syntax
and a collection of helpers built on c). You missed all of them except for
one. If the whole language was one helper function, you'd be right. But it's
not. Read up before you rant.

I don't know what convinced you that javascript is different from every single
other programming language enough such that classes are not useful, or why you
again propose that classes are the only thing coffeescript contains. They are
one helper function in a collection, and they are very helpful. I have used
them a number of times in production code for large companies and it's saved
me loads of time and made the code a lot cleaner.

If everyone had your philosophy, we would all be writing in assembly language
and/or c. Hell, why do we need a whole different language to make the syntax
nicer and contain helpers for common tasks? We could always just write a
function for it, right?

It's a weird perspective coming from a language you understand to an
abstraction that you don't, and that's why there are so many posts that say
this exact same thing. But you have to keep at it until you understand it
better, then the speed boosts and convenience will be worth every second.

~~~
Detrus
Here is another post about coffeescript from the author
[http://oscargodson.com/posts/writing-eloquent-javascript-
wit...](http://oscargodson.com/posts/writing-eloquent-javascript-without-
coffeescript.html) that pretends javascript best practices can be elegant
enough that you don't need coffeescript.

Best practices are nice, but it's even nicer when they're enforced by the
language so you don't have to see anyone not using them. So you don't have to
read books and search for tutorials on how to do basic stuff like inheritance
and choose from a zillion library options. Using coffescript you can at least
learn the top best practices in one place.

If you're using prototypal inheritance to do the equivalent of classical
inheritance, it would be nice to just say what you mean - class and super. The
JS language committee seems to hold this viewpoint, say what you mean with
keywords, instead of low level blah.prototype, blah.prototype.call(this). The
multitude of libraries handling this are inconsistent. If you read Crockford,
you might choose the style where everything private is in a closure, you're
not using prototype and taking a performance hit. Then if you do need
performance, if you have hundreds of instances, Crockford just screwed you and
refactoring should make you bitter.

Jeremy's own underscore has _.extend which is the cleanest, but to control the
wild west JS out there, the language should enforce one true way.

Nobody wants to know that ugly low level detail of blah.call(this). I can't
think of one example of JS code not using the equivalent of classical
inheritance. All these arguments against CoffeeScript seem silly when the
official language committee is adopting bits and pieces of it where they can.
If they could adopt the whole thing, they probably would.

CoffeeScript's real problem is debugging. No one complains much about it, but
it would be smoother to see bugs in CS instead of the generated JS.

