

In Which I Tell You to Stop Whining About CoffeeScript - bemaniac
http://singy.posterous.com/122451214

======
debacle
> Consider the closure syntax in JavaScript:

Proceeds to list example that isn't valid JavaScript.

I have no fundamental objections with CoffeeScript, but I will never use it
because there's nothing wrong with JavaScript that CoffeeScript improves upon.

For me, personally, it's way easier to visually scan a file that looks like
this:

var helloWorld = function () {

    
    
         // ...
    

}

Than this:

helloWorld ->

    
    
        // ...
    

It's also easier to grep and sed.

I don't mind if _you_ use CoffeeScript, but don't try and force-feed me some
BS about concise syntax, make broad generalizations (complex CoffeeScript _is_
harder to debug than JavaScript), or attack someone as a 'whiner' because they
said "It's nice, but not my cup of tea."

My thought process:

1\. In order to debug CoffeeScript, I will need to know JavaScript.

2\. If I run into a tricky problem, not only will I need to know JavaScript
but I'll also need to know the CoffeeScript compiler's internals.

3\. If I run into a really tricky problem, or if I need some sort of
optimization, I might have to use JavaScript anyway.

4\. JavaScript is actually quite a nice language to program in.

5\. All of the libraries I will be using will be written in JavaScript.

6\. wu.js ain't nuthin' ta fuck wit. [1]

Therefore, I'll keep using JavaScript. YMMV.

[1] wu.js is actually quite a killer library:
<http://fitzgen.github.com/wu.js/>

~~~
latchkey
The correct syntax is: helloWorld = ->

You just learn that -> == function() {}

That said, I found it hard to parse until I started working in it for a few
weeks and got used to it. Now, reading function() and {} everywhere seems like
a mess of boilerplate to me. Really, it is just a matter of what you are used
to.

re #3: Also, I can't think of an optimization that JS has that can't be
expressed in CS. It just doesn't work like that.

re #5: That seems like a kind of crazy generalization. How can you say that
when CS 'compiles' to JS anyway?

------
Zikes
My primary issue with CoffeeScript: people that use it insist that it's
JavaScript.

Example: I see a post on HN or in one of my RSS subscriptions about a great
new JS library or plugin, only to click through and see a page full of
CoffeeScript examples, and the source code is written in CoffeeScript as well.
This is not JavaScript. I will not learn CoffeeScript just to decipher your
plugin or library and integrate it into my JavaScript project. And no amount
of forceful whining on your part will convince me that it's so readable and
intuitive and minimal that there is no significant learning curve there.

~~~
avolcano
It is readable. It is intuitive. It is minimal, and it has a small learning
curve.

CoffeeScript syntax is very simple. It takes about a half-hour, at most, to
learn using the language overview (<http://coffeescript.org/>), assuming you
know JavaScript. There's also many well-commented examples you can learn from,
such as Conway's Game of Life:
<http://willbailey.name/conway/docs/conway.html>

Do you want to integrate a CoffeeScript library into your JS project? Compile
it (many CS libs already have a pre-compiled version available) and use it.
Hell, if you _really_ don't want to learn CoffeeScript, compile it without
minifying, and use the output for reference instead of the CS - it produces
more readable JS than some coders I know.

It really is that simple. You don't have to use it - I only use it for large-
scale projects - but you shouldn't get annoyed that people use it for their
libraries. I don't want to argue this issue much, but I just don't see any
difficulty involved here. I'm a terrible, still-learning coder who's still
baffled by every Lisp code sample I see, but CS was super easy to grasp. If I
can get it, I'm sure you can too :)

------
dustingetz
in which i tell you to take a look around outside your little bubble,

posts on coffeescript (and all posts about software) need to be taken in
context. This post's context, it seems, is the type of problem where your pain
points are, it seems, "javascript: the bad parts". Coffeescript is pretty
great at cleaning up the bad parts and if that's your pain point on a daily
basis then coffeescript is probably great for your team.

there are other classes of problems where your pain points are different -
e.g. layers upon layers of inheritance hierarchies, complexity on top of
complexity, bringing feature development pace to a crawl. Teams where all of
the grizzled engineers know javascript cold, know the idioms and thus are
rarely bit by "javascript: the bad parts". Switching from javascript to
coffeescript provides at most a small, incremental improvement to this class
of problems. These are the teams that are laughing at the OP. These teams are
also a hell of a lot more interested in ClojureScript, because it brings with
it a whole new toolbox of idioms to solve problems of complexity.

i think you one could take all the coffeescript blog posts, and sort them into
buckets of "loves coffeescript" and "just doesn't care", and these buckets
align perfectly with the two categories of problem i described.

Saying "at Posterous, they use it but don’t have any real JavaScript
engineers" is ad hominem and uncalled for, but if you squint past his tone,
he's saying: there are different kinds of software, and some problems are
harder than others, and it ain't one tool fits all.

~~~
ilaksh
LOL you're right, the solution to all of JavaScript's problems is LISP.

hahahahaha.

------
pestaa
Fully agreed. The syntactic sugar saves lots of time in total, and there are
few bonuses like

    
    
        for own key, value in hash
    

that also checks `hash.hasOwnProperty(key)`, which is good practice in
JavaScript, but really boring to type in almost all `for` statements.

I also observed that using longer, more descriptive variable and function
names, the difference between Coffee and compiled JS is definitely not an
issue in debugging sessions. I'd say there is not a context switch even.

It feels like thinking in JavaScript and writing in a new dialect.

~~~
masklinn
> but really boring to type in almost all `for` statements.

Use _.each, you're done. Pleasure.

~~~
cheald
Except that if you're, say, performing nested iteration, you end up creating a
whole crapload of closures, ballooning up memory usage and punishing the GC.

A quick test show that coffeescript's iterator is about three times faster.
<http://pastie.org/3783184>

Underscore's nice, but I really like Coffeescript's iterator sugar.

------
gavinlynch
I wonder where the blow-back is generated from. Personally, and only anecdotal
of course, I feel that I have seen a far greater amount of articles extolling
the virtues of CoffeeScript than I have seen condemning it. To be honest, that
is the only primary source of whatever trace of resentment I feel towards
CoffeeScript: I'm just almost bored of hearing about it. ( _tongue in cheek_ )

I don't use CoffeeScript, because Javascript suits me just fine. But I also
don't know many developers that slam it or recall an abundance of anti-
CoffeeScript articles... For whatever it's worth ( _shrugs_ )

~~~
leptons
The top articles about coffeescript posted in r/javascript are anti-
coffeescript articles.

There are many reasons not to use Coffeescript.

Some may claim that 'coffeescript is javascript', it really is not. They say
it with a straight face too. People that say this don't really understand the
difference between DOM and Javascript, and it is very telling. Just because
you can access DOM methods and properties using compiled coffeescript does not
mean that the coffeescript syntax IS javascript, and nothing could be further
from the truth. DOM is DOM. Javascript is Javascript. Coffeescript is
Coffeescript. Confusing them just makes someone look like they don't know what
they are talking about.

Anyway, javascript has been the only language used to code front-end websites
for quite some time (thankfully vbscript in IE is not used any more) and as a
result it has become very well know, widely written about, and quite a lot of
code has been written in it. There is a wealth of experience and all the
'gotchas' are well documented and there aren't really that many of them if you
don't count anything to do with the DOM. Coffeescript introduces its own
gotchas. While it may fix/avoid a few of javascript's gotchas, it introduces
its own. And worse, there are new releases of coffeescript that break
compatability, so much that the latest version of coffeescript now adds a
comment at the top of any generated code with the revision of coffeescript
used to create the "transpiled" code. If you think changing the rules of the
language regularly is a good way to develop software, then we don't have
anything further to talk about.

There are limitations to coffeescript that make it difficult to work with. You
can't have the same variable name used twice in the same source file. The var
command is ambiguous, and coffeescript's syntax is generally more ambiguous
than javascript leading to programmer error. It is more difficult to read
coffeescript because of ambiguity that you don't get with C style syntax.
Javascript uses clear delimiters { } for where things begin and end,
coffeescript does not and this means 'less typing' in coffeescript, but at the
cost of readability. Some say coffeescript is easier to read, more power to
them. Hopefully I'll never have to read their code.

~~~
gavinlynch
"The top articles about coffeescript posted in r/javascript are anti-
coffeescript articles."

Ah okay, r/javascript isn't in my regular rotation. So as I said, my only
evidence is anecdotal.

------
friggeri
In my opinion, CoffeeScript is not a language, it's nothing more that an
alternative syntax for JavaScript. The argument that one should know CS in
order to use a CS library makes no sense, it's nothing more than JavaScript
and I cannot stress that enough. Where it helps a lot though is that it does
remove a lot of JS bad parts and incorporates common patterns. Extending Array
in CS is nothing more than `class Foo extends Array` and it's perfectly
compatible with plain JS.

Basically, I do have more of a problems with libraries which add layers of
indirection (eg using _.each) at eval time when it could be done on CS at
compile time.

So, once again, CS is JS, written a little differently and with some nice
bonuses.

------
pjenvey
Source Maps will solve the line number mismatch problem:
[http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/)

~~~
lukeholder
was just about to post this.

Source maps are coming to coffeescript and will solve this. this article
doesn't mention them.

------
mkmcdonald
CoffeeScript is not a language. It's a compiler to make JavaScript look like
Ruby. Just like the superfluous idea of "semicolons are optional because of a
design error", it's personal style.

Be sure not to whine, though, when the abstraction leaks and your code breaks.

~~~
petercooper
To make JavaScript look like _Python_ , even. List comprehensions, significant
whitespace, etc.

~~~
exogen
I thought this too, at first, but only because I didn't know Ruby very well.
Now I realize it's heavily inspired by both, but actually more closely
resembles Ruby, IMO.

------
latchkey
I wish I could say blog posts like this helped the cause, but my feeling after
reading it is just meh. I'm fanatic about CoffeeScript but there will always
be a divide between people who are willing to try it and people who won't.
Writing blog posts that effectively regurgitate the documentation while being
a bit religiously pushy about it just seem kind of counter to the cause.

~~~
slantyyz
Reading the article, I think it's the opening blockquote that got the author's
dander up:

>> For example, at Posterous, they use [CoffeeScript] but don’t have any real
JavaScript engineers.

The OP probably should have ignored it, but sweeping comments implying that
Posterous developers aren't JS engineers is bound to get a response.

------
gfodor
Javascript for novices? On the contrary, CoffeeScript is Javascript for
_professionals_.

~~~
insin
s/professionals/Ruby fans/

~~~
gfodor
I was going for brevity but the downvotes tell me I said too little.
CoffeeScript is a tool by and for experts. I don't know where people got the
idea it is there to help newcomers. It's clearly an opinionated abstraction
that is designed around removing the things that are grating to deal with as
professional JS programmers on large code bases. The benefits on a line by
line basis are small, but on a large project these small things (unfairly
labelled as sugar) compound into large scale effects like a cleaner, leaner
code base.

~~~
wwweston
Part of your comment might be related to why CoffeeScript gets blowback --
there's an implication that if you're _not_ using CoffeeScript, then you're
not an expert.

------
ilaksh
I think a lot of the discussion about why CoffeeScript is or isn't better is
really a proxy for the real issue which is, is it worth taking the time to
learn it.

People generally are motivated by feelings and the rationalizations come
after. For awhile I felt like I did not want to learn CoffeeScript and that it
was silly and annoying that people wanted me to waste time learning it.
Honestly what really started to change my mind was that I needed to alter
PDFKit, and I had to learn a little bit of CoffeeScript in order to do that. I
think that the need to learn it came first and then later the rationalizations
for why it was a good choice came after.

Another real issue that is below the surface but not mentioned while people
are discussing the actual pros and cons of CoffeeScript: is JavaScript a good
language, or is it fundamentally flawed somehow?

A professional JavaScript programmer's identity will often be tied in to some
degree with his general JavaScript associations (the same way someone who
races Formula 1 cars would identify with that type of car and might be
offended if someone started attacking the body shape of those cars), and so to
make a significant investment in learning CoffeeScript implies fundamental
issues with JavaScript and may therefore be an attack on that person's
identity. Obviously this wouldn't be a conscious thought process but the
subconscious associations are often there.

Whatever is making people choose to learn CoffeeScript or not to learn it, its
not really a rational process usually. Its more like a religious battle.

I think that the amount of time you have invested in JavaScript, how well you
really know it, to what degree you have come to terms with/got over those pain
points that CoffeeScript helps with, how much you identify with JavaScript
versus other technologies, whether you actually have a specific need to learn
CoffeeScript (i.e. for altering a library or reading a coworker's code), all
of those things are going to add up subconsciously in a sort of vector for or
against CoffeeScript that is pretty much an emotion which will motivate
different rationalizations about specifics.

So in cases where that subconscious equation just isn't adding up in
CoffeeScript's favor people will find all sorts of (often tangential)
arguments against it. One thing that probably can help if you are trying to
push CoffeeScript is to repeatedly mention certain small improvements such as
using -> instead of writing function() or the class and extends syntax. That
would mean that they would have to learn those things just in the process of
the discussion. (Of course, they may want to stab you if you mention those
things too many times though.)

~~~
MatthewPhillips
I think you come close to saying something very important but don't quite
explicitly say it so I will.

CoffeeScript is a proxy war between JavaScript and Ruby developers. That's the
whole "controversy" over CoffeeScript, to semicolon or not to semicolon, and
everything in between.

JavaScript developers feel threatened by the influx of Ruby developers into
their space and Ruby developers want to turn JavaScript into Ruby and get rid
of those ghastly curly braces that cause them to have a panic attack.

Let's call a spade a spade.

~~~
ilaksh
Good point. I hadn't thought of it that way actually but that has got to be
part of it.

For me, I sort of skipped over Ruby. I was too busy with other things to
really get into it. So since I had more experience (not a lot, but more) with
Python than with Ruby, that is what CoffeeScript seems like to me, instead of
Ruby.

I always liked Python syntax, its just that I was busy with projects that
involved a lot of HTML/CSS/JavaScript/PHP etc.

I have spent years and years writing C#/C/C++/JavaScript/PHP code with curly
braces etc. To me, the curly braces and some other stuff are noise. Especially
when you get into callbacks and have to remember to keep all of your curly
braces and parenthesis straight. Its basically stuff that, as demonstrated by
CoffeeScript, the compiler can take care of for you, but in JavaScript it just
wasn't taken care of.

In a similar vein, JavaScript (and any other dynamic language or language with
static type inference) demonstrates that type declarations aren't necessary,
and that a language/compiler can usually take care of that stuff for you.

In a similar vein, C demonstrated (among other things) that managing the stack
manually isn't necessary.

Ruby syntax to me is significantly more complicated than CoffeeScript and not
really as clean (begin end blocks etc). I think that Rails has some important
advantages in terms of software engineering, but the performance and syntax of
Ruby turns me off a bit. Still, there is probably more good than bad so I
might still end up doing some Rails stuff.

I don't think its advantageous to write an if statement backwards and I think
people who wear black wire-rim glasses when they can easily afford contacts or
don't even need lenses are ridiculous. I also have never owned a Mac in my
life. I dual boot to Ubuntu/Windows 7.

------
meanguy
I converted some old, overcomplicated, YUI-inspired javascript that relied
heavily on class inheritance: big win. I converted some events-gone-nuts code
that talked to Google Maps: not a win.

The productivity issue that nobody seems to talk about: the damn compiler is
slow. We're talking seconds, but it adds up. (The CSS compilers are far
worse.)

I'm used to save/refresh/boom! when coding HTML. Now it's save, contemplate
what the hell could possibly take so long, stare sadly at the compile output
window, tab, reload, oops, reload again.

------
rikthevik
I love the great interaction between backbone.js and coffeescript. It's not
often that you get two pieces of software that work so well together.

~~~
ewb
How in particular do they work well together? Backbone is something I've been
meaning to try out.

~~~
lowboy
They work together about the same as CS does with any JS module/app.

Backbone apps tend to have a lot of references to _this_ and use a lot of
object literals, so there are some saved keystrokes I guess.

------
pascalr
I can't believe so many people fight over a syntax. In a perfect world, you
wouldn't even care about the syntax that others use because it would
automatically be translated into the syntax of your preferences when you look
at it.

------
CCs
It's a matter of taste.

If you like Ruby, check out CoffeeScript.

If you don't now there's Google Dart. The IDE is pretty nice.

None of the above? Closure Compiler, jshint etc. are your friends.

Edit: a good article about "verbal vs visual" programming languages:
<http://ryanflorence.com/2011/2012/case-against-coffeescript/>

~~~
leptons
Or you could, you know, just learn javascript like a billion other people.

~~~
CCs
That's the "None of the above" part.

All of these are just tools to help you get it right. Even with plain
JavaScript you will need tools. jshint for example is awesome.

------
njharman
I agree with OA spirit. But under "More than sugar" he only mentions surgary
things like conciseness, readability, and saving time.

Also the title is total bull dooty, instead of saying what the title implies;
"CS, it's for some, not for others. Shut up already." Or better yet not
posting this crappy blog in first place. OA retreads the same horse beatings
everyone else has ad nauseum.

------
geuis
I just finished a contract at a company of very smart engineers who decided to
use Coffeescript way before I got there.

The guys that I was working with were _way_ more brilliant than I am. Guys
that have machine learning books on their desks for lunchtime and are doing
some amazing work that is going to benefit hundreds of millions of people
around the world.

To reference this quote from the article: "Any respectable CoffeeScript
engineer should have a strong knowledge of JavaScript".

That, frankly, is not true.

One of the reasons I was brought on was to work on some javascript-heavy
stuff. I was a newbie to coffeescript beforehand, so to hit deadlines wrote
everything in vanilla js to save time and get work done. The guys on the team
are very smart, but not really on top of the javascript game. So in this case,
coffeescript was definitely being used because it was easier for them as
traditional programmers.

Earlier this week, I spent a couple days and finally went through and ported
everything over to CS.

In my experience of having manually written a complicated client-side app in
js, then manually ported it to coffeescript, I really just don't like CS.

I'm used to Python. Indentation there is natural. Its idiomatic to what Python
is. But its not in javascript. Granted, indentation should always be used in
js for readability, but brackets really are needed to denote code blocks.

Another complaint I have against CS is that it tries to do so much stuff "as
if by magic" that I was never 100% what my code was going to output. I just
find:

    
    
        abc (arg,arg2) ->
    

to be really fucking confusing. Not to mention adding in the fat arrow, or
'do' if you need to wrap something in a closure.

I'm probably old school, but when I write code I need to know explicitly what
it will do. I know what 'this' will refer to based on how I write. Same for
closures.

Lots of times, my original code was just as concise as the coffeescript
version, and a hell of a lot more concise than what CS rendered out.

So everyone has their opinions, likes and dislikes. For me, I'm gonna stick
with native javascript for the time being.

~~~
lowboy
> I'm used to Python. Indentation there is natural. Its idiomatic to what
> Python is. But its not in javascript. Granted, indentation should always be
> used in js for readability, but brackets really are needed to denote code
> blocks.

Why are brackets _needed_? Eliminating braces makes code easier to write and
read (IMO) and I'd appreciate almost any indented language to follow suit
where possible.

> I'm probably old school, but when I write code I need to know explicitly
> what it will do.

I've found this is mitigated by experience with CS. Just takes a small amount
of time getting to know the language. Nowadays I have a pretty good idea of
exactly what JS will be output when I'm writing CS.

> Lots of times, my original code was just as concise as the coffeescript
> version, and a hell of a lot more concise than what CS rendered out.

Concision in this case might be in the eye of the beholder. I find the
outputted JS to be quite readable (the most important aspect) and I know what
to look for and how to map it to my source code.

Would I recommend porting all of your existing JS to CS? Hell no! But I'd give
CS another try for a new project and see if you like it. I think it would
click if you used it to actually program toward an end rather than port
existing JS. I can see the latter being frustrating, seeing how many different
patterns there are for JS development.

------
robwgibbons
I don't use CoffeeScript, among other reasons, because honestly it's just
another syntax to learn and remember. Despite what people say, it's not "just
JavaScript." I write JavaScript everyday, as well as CSS, HTML, Python and
PHP. Adding one more syntax layer to the stack, with its due postitives, also
comes with its own costs. As for speed, I utilize tab completion in my editor
and make advanced use of keyboard shortcuts, which makes my writing/editing
more than "fast enough."

