
This is CoffeeScript - franze
http://robots.thoughtbot.com/post/9251081564/coffeescript-spartan-javascript
======
Spyro7
I am a recent coffeescript convert. When I first heard about coffeescript I
dismissed it offhand as a pointless abstraction over javascript, which I
judged to already be a high level language. (In retrospect, I am ashamed to
say it, but I think that I found the syntax to be intimidating.) I then went
on to continue, happily, writing thousands of lines of javascript.

Somewhere along the way, I came across Paul Grahams essay "Succinctness is
Power" ( <http://www.paulgraham.com/power.html> ), and I thought about how my
productivity could be increased if I had access to a language that offered me
the ability to do more with less. That was when I decided to revisit
Coffeescript.

For my first task, I decided to rewrite some of my simpler javascript code
into Coffeescript just to get a feel for it. Initially, the things that had
initially repulsed me were somewhat irritating:

* The lack of parenthesis and brackets - I doubted that it would be possible to maintain code readability without them

* The reliance on indentation

* The overall "strangeness" of the appearance of coffeescript code (to someone with a predominantly java background)

Here's the thing though. All of those objections are only surface deep. Once I
actually started to code in Coffeescript, I found that I became completely
comfortable with the syntax. As a matter of fact, I don't think that I could
ever go back to conventional javascript again. Especially because I would lose
(among other things):

* An elegant syntax for writing classes using javascript

* List comprehensions

* Elegant string interpolation (it's the little things that count)

It is easy to be skeptical about coffeescript if you natural lean away from
things that are surrounded by hype, but, take it from me, coffeescript really
is an extremely valuable tool that no web developer should be without. It is
more than just a way to write pretty javascript. It is a powerful, flexible,
and elegant language in its own right. Don't be turned off by its syntax, give
it a try today!

------
collint
"Just like JavaScript but nicer to type." was a decent pitch to make
CoffeeScript sound safe. But it's become so much more. And you get past the
simplicity of that pitch quickly if you use CoffeeScript earnestly.

Going through the Table of Contents on <http://jashkenas.github.com/coffee-
script/> I've picked out the features of CoffeeScript that make it a different
beast than just a JavaScript without warts.

* Lexical Scoping and Variable Safety * Conditional Assignment * Splats * Comprehensions * Everything is an Expression (&implicit return) * The Existential Operator * Classes, Inheritance, and Super * Destructuring Assignment * Function binding * Chained Comparisons * Extended Regular Expressions

This is beyond a simple sweetener for your JavaScript code. Yes, you could
write your JavaScript like you write your CoffeeScript, but you wouldn't.

Try this little jewel in Try CoffeeScript and you'll see what I mean:

[open, contents..., end] = "<impossible>".split "" alert contents.join ""

~~~
boucher
I think the jury is still out on whether or not the existential operator is
too clever for its own good (in particular when used as part of a chained
expression).

~~~
collint
What is so clever about a nil object check?

I suppose if you're using it to make skirting the "Law of Demeter" and thats
something you don't want to do it could seem like something bad.

But I'll take "foo?.bar()" over "foo.bar() if foo" gladly.

~~~
Cushman
The issue is in an expression like "out = foo?.bar()". What I want is to only
assign to out if foo exists, but the compiler has no way of knowing that--
it'll evaluate to undefined instead. In this situation I need to use "out =
foo.bar() if foo".

That's easy enough to remember, though.

------
akdetrick
I don't subscribe to the notion that you can write code faster with less
keystrokes (vi/emacs, anyone?). I do however, understand that a cleaner syntax
would lend some readability and simplicity to your code once you learn said
syntax. Ultimately, I find that the problems that CoffeeScript solves, and
solves quite well, are not really that big of a deal for me given that I've
been working with Javascript enough to get used to the quirks. I'm not sure if
I'll ever use it myself, but I can't blame anyone who would; this article does
a good job explaining some of the benefits.

~~~
danenania
"Ultimately, I find that the problems that CoffeeScript solves, and solves
quite well, are not really that big of a deal for me given that I've been
working with Javascript enough to get used to the quirks."

I wouldn't expect you to believe me until you've used CoffeeScript for a
little while, but I think you're definitely wrong about this. CoffeeScript
simply has _better_ syntax than plain js in every way, and any js developer
will be more productive using it. The only drawbacks are dealing with file
conversions and debugging, but these are something like a 10% penalty at worst
on top of a 100%+ productivity boost. It's not just an aesthetic preference
thing. CoffeeScript is a much better language and is pretty much guaranteed to
save you time and mental effort.

~~~
awj
> CoffeeScript simply has better syntax than plain js in every way, and any js
> developer will be more productive using it.

That's a pretty bold claim. Have any examples to back it up? Most of what I've
seen of coffescript (note: I haven't looked hard) seems to be relatively
similar syntax with fewer characters or fixing JS gotchas that many developers
are familiar with.

Both of these are useful things, but they don't make a 100%+ productivity
boost in my mind.

~~~
Cushman
List comprehensions. Distinct 'of' (property) and 'in' (value) operators. Bind
a function to current 'this' with =>. Nothing winds up in global scope unless
you mean it. Use reserved words as property names. Existential operator and
assignment. Always use '==='. Everything is an expression:

    
    
        value = switch value
            when 1 then one
            else whatever
    

Closures.

    
    
      do (value) ->
         #value is wrapped in a closure
    

The 'class' macro.

And that's just off the top of my head. Yes, it compiles to JavaScript. You
could write all this by hand. It would be a waste of your time-- CS writes
safe, efficient, readable code faster and better than you do, every time.

Look harder.

~~~
te_chris
Peoples' obsession with CS having the class macro is weird to me. Seems like
laziness more than anything - once I grokked JS's protoype object model I've
found it to be ridiculously powerful AND I got to learn a cool new programming
abstraction at the same time. All the rails guys I know are going gaga over CS
but I just don't see the point as I like and can be efficient in JS.

~~~
Cushman
I can't speak for anyone else, but I treat the class macro as pure shorthand.
I understand implicitly that "properties" in a "class" are being assigned one
at a time on the constrictor's prototype, and frequently use that knowledge
for metaprogramming. You call it laziness; I call it nicer syntax.

I understand that puts me in a small boat. In my opinion, people shouldn't use
the class macro without knowing what it really does. Actually I'd extend that
to say people shouldn't use CoffeeScript at all without an understanding of
the JavaScript it compiles to, just as you shouldn't use C without an
understanding of the assembly it compiles to... But that's probably wishful
thinking. It wouldn't be an improvement for those people to write assembly (or
raw JS) instead.

------
maccman
Also, HNers may find my open source book on CoffeeScript useful: The Little
Book on CoffeeScript <http://arcturo.github.com/library/coffeescript/>

------
tlrobinson
Am I the only one who thinks this is horribly difficult to visually scan?

    
    
        item = new Item title: "Awesome", id: 2
    

Less isn't always better. I like the parens, at least if there's more than one
argument.

    
    
        item = new Item(title: "Awesome", id: 2)
    

It's much easier for me to glance at this and know what's going on.

~~~
jrockway
What else would it mean?

~~~
tlrobinson
I can understand what it means, it just takes slightly longer to comprehend
without the parens providing a visual cue that it's a function call.

It only gets worse with nested function calls:

    
    
        item = new Item title: new Title "Awesome", id: 2
    

The syntax isn't ambiguous, but that doesn't mean it's easy for humans to
parse.

------
bilalhusain
When I first checked out coffeescript, I had a feeling that Jeremy was
unfairly trying to show it off as cool by being less verbose than javascript -
a feeling I found echoed in one of the tweets by Zed. But after actually using
it, I realized that I had missed the whole point.

Coffeescript has that ruby-esque intuitiveness. A lot of time I refactor code
on a gut feeling that it'll work, coffee -p, yup it does ... 9 out of 10
times. closure, is, in, of, soaking null references lets you focus more on
your code rather than on patterns, handling corner cases and avoiding
mistakes; and I just discovered the fat arrow thanks to this post. (Yup, the
documentation is all there on the homepage but, agree or not, learning is
incremental and involves mistakes and serendipity.)

~~~
jashkenas
Dug up Zed's tweet: <https://twitter.com/#!/zedshaw/status/101746443949322240>

... which does indeed miss the point -- the side-by-side comparison on the
homepage is not to show you what the equivalent handwritten JavaScript would
be -- it's the actual JS output compiled from the CoffeeScript on the left.
More of a "nothing up my sleeves" and no bullshit maneuver.

In a perfect world, CoffeeScript would compile into the JavaScript you would
have written in the first place -- but that's quite a tall order.

~~~
ori_b
If you're doing a side-by-side comparison, then you want to compare with what
a human would write, not with what a compiler would write. Otherwise, you're
not really showing the advantages of your language, you're showing how easy it
is to read the object code -- something that's only really an advantage when
debugging your compiler and/or trying to map the generated output back to the
source for debugging purposes.

I mean, look at what Hello World in C is, compared to Hello World in Haskell!

<http://pastebin.com/sePpUJ1J> (Haskell source)

<http://pastebin.com/seqAy4VD> (C, generated from the Haskell above)

Clearly C is unreadable garbage! (It's less expressive than Haskell, for sure,
but showing generated output makes it look far worse)

~~~
danielmason
"What a human would write" isn't the purpose of the comparison. "This gets put
in, this comes out" is. Did you not read the heading on the overview page? It
doesn't even say "comparison" anywhere. The second paragraph talks at length
about how CS compiles to readable Javascript. Then the examples show you that
readable Javascript. You're missing the point.

~~~
ori_b
Why do I care if the output javascript is readable? It's object code. I don't
want to care about it.

~~~
tomfaulhaber
Unlike environments like GWT or ClojureScript, coffeescript doesn't treat the
JavaScript as an invisible target language. You do actually think a little
about the JavaScript that your code is being compiled into (or maybe more
accurately, translated into).

This makes CoffeeScript fit really well into the JS-centric environment that
has grown up around tools like JQuery and backbone. It's also very easy to
debug in the browser compared to the environments that are targeting JS as an
object code.

Personally, I don't think of CoffeeScript as a fully independent language but,
rather, as a way to write JS which is cleaner, more reliable, and more fun.

If you really want to turn JS into a black box (and there are some good
arguments for that), GWT or ClojureScript might be better choices for you.

(I've been writing a bunch of CoffeeScript lately and loving it. I'm very
anxious to try my hand at ClojureScript also. GWT has always seemed very
unwieldy to me.)

------
TrevorBurnham
I'm the author of the PragProg book on CoffeeScript
(<http://pragprog.com/book/tbcoffee/coffeescript>), and I run @CoffeeScript on
Twitter.

It's always fun to see a "CoffeeScript rocks" article like this explode on HN
and Twitter. But it's even better to see stuff that people are building in
CoffeeScript. The language has reached the point where it's gaining real
traction in production settings, and not just among the beautiful code addicts
at 37signals. There was a YC job posting about a week ago for a "CoffeeScript
drinking frontend engineer" (<http://news.ycombinator.com/item?id=2877677>);
they're also using CoffeeScript for a Node.js server, and even for MongoDB
queries. I'm really excited to see that become a more common occurrence.

------
dreamdu5t
The bottleneck is never the time it takes to type the code.

Honestly, CoffeeScript is neat but it's not much of an improvement over JS.
It's just as ugly and unreadable. It's only an improvement if you're counting
characters.

I don't find CoffeeScript any less ugly or readable than JS. It seems
incredibly redundent.

~~~
alfbolide
true we should all write machine code.

~~~
Almaviva
If someone likes x over y, it means they must like the most extreme thing
possible that is different from y in the way x is!!

Why make that point? It has absolutely no intellectual content.

------
seanalltogether
It seems like the removal of parenthesis is a bad idea, because it's bound to
create a bunch of inconsistent code. Notice how all the rest of the code
samples on the page keep the parenthesis in?

~~~
bstar77
I approach this the same way I approach Ruby... I only use parenthesis when
they improve readability of a confusing statement or are required (function
call with another function call-with params-as a param). As you can see, this
statement required parentheses ;-)

------
franze
note: below the pics is an actual readworthy article.

~~~
pointyhat
Thanks for the heads up. I didn't get that far initially.

------
dstein
The problem with Coffeescript is if you already know JavaScript, it's
completely unreadable. Looking at code like this, I have absolutely no idea
what it does:

    
    
      class ItemView extends Backbone.View
        render: ->
          @options.items.each(@renderItem)
        renderItem: (item) =>
          @el.append item.get("title")
    

It doesn't make sense because there are magic variables appearing out of
nowhere - @options, @el, append -- what are these? I'd have to study the
resulting JavaScript to understand what it's really going to do.

~~~
qrush
How is that not the case for any language?

(This also might be a bad example, but it was based off of code I wrote)

~~~
dstein
Coffeescript is adding an abstraction level, but all the complexity of
JavaScript remains, so while you write Coffeescript, you have to sort of
compile it in your head. I could maybe get on board if it went one whole level
of abstraction further.

~~~
adambard
I disagree; I think the more standard handling of `this` and the automagic
variable scoping, constitute a significant reduction in complexity for people
coming from other OO languages. Certainly for me, having more experience with
Python and Ruby than Javascript.

The abridged syntax is just gravy.

------
7mythie
I've been playing around with coffeescript for a month now and I'm still
undecided about whether these punctuation marks improve the syntax or not.
Typing out "function" doesn't really take that long and it's much more
readable than "->". On the other hand, I miss the parentheses and semi-colons.
Without those punctuation marks the code feels more ambiguous. Maybe I'm just
stuck in my ways, hopefully something will click soon.

------
dmix
I've used CoffeeScript extensively with a backbone.js project I was working
on. I really liked it (and backbone).

But I haven't been able to bring it into my main rails app since I'd like to
have all of my JS consistently in coffeescript. I don't like having both
JS/CS, just like I don't like having HAML/ERB mixed together.

It would be a big project migrating it over and not as simple as HAMLizing a
project.

Maybe one day I'll do it, or wait for a future rails projects.

~~~
DevX101
There's a javascript to coffescript converter:
<https://github.com/rstacruz/js2coffee>

Although I did have a few problems with some more complex code, it seemed to
do the trick for more straightforward javascript. You'll lose your comments,
but it's worth checking out.

------
donpark
First week of using CoffeeScript, I was mostly writing code and it felt
foreign. Second week, same but it now felt convenient and I used it like a
DSL. Third week, I was reading code as much as writing it and it suddenly
became essential.

CS does have some rough spots that feels at odd with rest of the language but,
overall, it brings clarity and convenience at minimal cost.

------
statictype
My only major complaint with Coffeescript is that it doesn't have a construct
for handling the context-sensitive 'this' keyword. I still have to write

    
    
        self= @
    

at the top of functions. The fat arrow for binding 'this' certainly helps but
when you have to be really careful when writing code that nests several
functions.

Also, would be nice if the for-loop had a way to automatically wrap the block
in a function without having to write

    
    
        for(var x in lst) do (x) ->
                  whatever(x)

~~~
M1573RMU74710N
I'm not sure I understand your first complaint.

The fat arrow is a great helper and saves a lot of work in various
situations....obviously it doesn't cover all situations...but in the
situations it doen't cover I'm not sure what I'd expect the language to do.

Could you give an example of what you imagine the feature to be?

I'm just not sure if something as simple and easy as

    
    
        that = @
    

needs improvement. Anything beyond what that and => covers, to me seems like
something a library should handle...and CS makes that very easy.

For you second one, what about

    
    
        do ( -> whatever x ) for x in foobar
    
    

One of the things I like about CS is that it is very conservative about not
adding helpers for every little thing you can think of. It chooses a few
_very_ powerful and fundamental building blocks, and let's you use those to
build up yourself.

I can respect some people wanting more though.

~~~
statictype
I did not know about the

    
    
        do () for x in foobar 
    

syntax. Thanks.

------
scubaguy
Perhaps the biggest strength of CoffeeScript is that it takes JavaScript,
where there are many different ways to do OO inheritance; write and use
functions; perform functional tasks such as list comprehension and provide a
consistent and simplified syntax to do them. Because CoffeeScript is language
designed how JS developers write code today, it feels more natural and fluid.
It makes JS programming simpler.

------
jvoorhis
Why raise so much snark straightaway about keywords, and then gripe about the
silly ones later?

I've written thousands of lines of JavaScript, and a coupla hundred of
CoffeeScript. CS is a usable, rather polished JS overlay, but I only
understand it in terms of JS. In any case, I know which will be around longer.

------
scdc
>var html = "<option value='" + this.id + "'>" + this.get("title") +
"</option>";

>This is such nonsense. Why did we put up with this? In CoffeeScript, you can
write:

>html = "<option value='#{@id}'>#{@get("title")}</option>"

I have to say, the first one is much easier for me to read and understand.

------
alfbolide
The fat arrow by itself make it a mandate for everyone who wants to write OO
js write Coffeescript.

------
MHBerryman
Just thought I'd share the CoffeeScript + jQuery article in Septembers issue
of Linux Journal:

[http://www.linuxjournaldigital.com/linuxjournal/201109/?pg=3...](http://www.linuxjournaldigital.com/linuxjournal/201109/?pg=32&pm=2&u1=friend)

------
funkah
I agree that "function" is too long, but I'm not a huge fan of these arrow
keywords because they're not very easy to type. But something like
TextExpander would make a simple fix.

~~~
chc
The arrows are easy enough for me. Middle finger hits the - or =, pinky hits
shift and index finger hits >. It's drastically less finger-work than f-u-n-c-
t-i-o-n-shift-(-)-space-{-}. The only languages I can think of off the top of
my head with easier syntax for anonymous functions are Scala (a pair of
parentheses is literally all you need) and Clojure (with its #() syntax),
which both seem to have put a lot of effort into making them easy.

In particular, Ruby and Python both require more typing. At their most
concise:

    
    
      Ruby:   -> {}
    
      Python: lambda:

~~~
thezilch
You may be stuck with your IDE:

    
    
      JavaScript: fu<tab><shift-)>
        function(){
          <cursor>
        }
    
      Python: la<tab>:
    

The remaining characters should be filled in by most modern IDE / IDE plugins.

~~~
chc
Those are both still more work than ->, and you could make a shortcut for the
arrow as well if it's so difficult. Anyway, my point is that I don't see why
the arrow should give anyone with a normal keyboard layout an inordinate
amount of trouble compared to similar constructs in other languages.

------
freddealmeida
points for using 300 to explain coffeescript

------
perfunctory
anybody wants to guess what this code compiles to?

    
    
      a [1] = 2

