

CoffeeScript: The beautiful way to write JavaScript - jashkenas
http://amix.dk/blog/post/19612

======
jherdman
I can't shake the feeling that people that like CoffeeScript are those that
don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas
JavaScript has none -- let go an embrace the prototypal object model).
Further, most (if not all) of the examples of the problems with JavaScript are
null and void. A language that combines paradigms? Most do. Sure, the name
sucks, but that's hardly an issue.

I understand that syntax may be more convenient for some, but this is
indirection, and is a source of complexity that may impede collaboration from
other devs more familiar with JavaScript.

~~~
hermanthegerman
I have to say that by using cs I learned a lot more about js. Maybe for old js
cats it doesnt matter, but I only used js occasionally before, and now it
became one of my favorite languages (I use with node, and I write all my node
stuff in cs).

One particular example that changed everything for me was the natural and
simple way I could build the typical callback constructs with -> and => , so
they almost look like blocks in ruby, and feel way more natural as a control
construct, and I didnt have to stack lots of })}); and so on.

If you're rather new to something, the ease of use and the simplicity and
readability speeden up the learning process extremely.

That being said, there are also a couple of things in cs that are kind of
silly.. like using 'for i in my_array', but 'for k of my_dict', and stuff like
that, that are really hard to debug.

Although, in terms of debugging, the fact that it gets compiled and possible
errors are early detected and a canonical js is generated also saved me lot of
time, in particular with IE ;-)

~~~
jashkenas
To explain the reason for the "in/of" distinction...

"for item in list" vs "for key, value of object" is an unfortunate necessary
evil. It would be great to use the same keyword, "in", for both types of loop,
but I'm afraid there's no way for us to know at compile time if "list" or
"object" is really an array, or really an object.

~~~
boucher
I'm curious, why do you need to make a distinction? Is there some other
feature of CS that depends on it? Certainly 'for key, value of array' could be
implemented with numerical keys. If using just 'for value of dict' is allowed
that would also work fine.

~~~
jashkenas
We need to make a distinction because we want to have arrays be iterated over
with:

    
    
        for (var i = 0, l = list.length; i < l; i++) { ... }
    

And objects iterated over with:

    
    
        for (var key in object) { ... }
    

Using a "for-in" loop over a JS array isn't acceptable, for performance and
semantics reasons, and neither is sniffing at runtime to determine whether the
object passed is an array, or an object.

Ideally, JavaScript would have supported a single iteration protocol for both
arrays and objects from the get-go, but alas...

------
JoelSutherland
I couldn't agree more.

The biggest problem with CoffeeScript adoption is the administrative overhead
required for novices to get it running. This means that most CoffeeScript
projects are usually larger -- it just doesn't get used in small one-off
things.

My company's product is a hosted CMS and we just tackled this problem
(<http://www.gethifi.com/blog/hosted-cms-coffeescript-support>) by completely
eliminating the workflow issue. You can use Coffee or JS and the system takes
care of the rest for you.

I've found this to be a big help when working on smaller client sites. Often I
just need to write a couple dozens lines of JS and it just isn't worth the
hassle to do it in Coffee -- now it's gravy.

~~~
munificent
I started toying with CoffeeScript a while back for my own entertainment and
found the administrative overhead was _much_ less than I anticipated. I went
from a clean slate to being up and running in like five minutes. Once I had
node and CoffeeScript installed, it was just a single command-line to start a
watch on my .coffee file and then I was back to "refresh browser window to see
my changes" mode just like regular JS.

------
nexneo
This is almost copy of CoffeeScript manual (plus some old jokes about
Javascript)

Read original here, <http://jashkenas.github.com/coffee-script/>

------
justrudd
I've done my fair share of web programming. But JavaScript (for me) has always
been to add the flash, not to write the app. In the past couple of months, I
dove into Backbone.js, Sammy.js, etc. and while my JavaScript worked, it
wasn't "the JavaScript way".

When I found CoffeeScript, I was very happy. But I've been moving back to more
JavaScript recently because I've spent hours looking through the generated
JavaScript and learned quite a bit from it. I did the same with my C compiler
and x86 Assembly :) It's nice to read what the experts think the final product
should look like.

So write some CoffeeScript, compile it, and learn some JavaScript from it.

~~~
astrodust
If you can't debug in CoffeeScript, you can't take it seriously. Even meta-CSS
frameworks suffer from this problem when there's errors you have to back-track
through a whole layer.

------
endtime
I love CS, but this article doesn't seem to have much useful content that
isn't arleady in the CS docs: <http://jashkenas.github.com/coffee-script/>

~~~
derwiki
Nope, but I read this article and then read the CS docs -- which I wouldn't
have done if this article wasn't posted.

------
davepeck
Out of curiosity:

What's with today's obsession over beautiful syntax? Shouldn't we strive for
beautiful semantics, instead?

~~~
jashkenas
Absolutely, but the idea here is a bit different. JavaScript is a language
that we're stuck with for the entire foreseeable future of the web, for better
or for worse ... and CoffeeScript is a conscious attempt to try and work
within that limitation. Unless you're willing to take the significant
performance hit of running an interpreter on top of JavaScript, you have to
stick fairly close to JavaScript semantics.

That said, we certainly try to improve upon JS semantics, where it's possible
to do so without a performance hit. Things like auto-lexical scoping, bound
functions, chained comparisons and, most importantly, "everything is an
expression", are all examples of this.

~~~
neimado
No, you aren't trying to "improve JS semantics", you are trying to 'Rubyify'
Javascript. You've created a language that is NOT javascript. Sorry, but no
matter how hard you try to sell it as === javascript, it still will never be
javascript. It's a Ruby syntax wrapped around javascript with some bells and
whistles. It isn't a solution for javascript programmers, but it might be a
solution for Ruby programmers.

~~~
tianyicui
It might also be a solution for programmers who don't tend to label themselves
"LanguageX programmers".

------
MatthewPhillips
I've had trouble learning CoffeeScript due to the compiler not providing any
help whatsoever when you make a mistake.

I was writing a web server that just wouldn't compile, looked the code over
several times and eventually gave up and did it in javascript instead. Later
found out that Gedit was displaying a tab that vim showed as just being a
space. Never tested if that was the only problem or not.

~~~
TrevorBurnham
Agreed. The compiler definitely isn't as helpful as it could be in giving
information about errors. On the other hand, a lot of the errors it hits at
compile-time are things you wouldn't have noticed until run-time if you were
writing JavaScript.

------
barmstrong
I would love to see javascript turn into assembly language. Google has already
done with with GWT with great improvements in productivity.

One question I had while reading this. Was there a technical reason why he
didn't make a gem or toolkit in pure Ruby or Python that would then spit out
Javascript?

I think this is closer to how GWT did it where you can write pure Java, and of
course it then wouldn't require people to learn a new language.

~~~
oscilloscope
The issue is Ruby/Python/Java's semantics don't map perfectly to JavaScript.
As it says in the documentation, the golden rule of CoffeeScript is "It's just
JavaScript".

For people who know JavaScript, it's not a new language-- just some syntactic
sugar and a few bonus features.

------
knv
I wonder if it's feasible to hack the javascript engines (v8, spidermonkey,
...) to support languages CoffeeScript? In case the answer is positive how
come nobody's doing that?

------
dstein
I really wanted to like CoffeeScript but that it can't be metaprogrammed and
serialized (easily) is a huge problem for a scripting language. I guess
scripting was never the point of CoffeeScript, but a lot of what makes
JavaScript so flexible is lost when you add a compile stage.

~~~
mrkurt
I'm struggling to think of something I can do in Javascript, but not
CoffeeScript. Can you give an example?

~~~
dstein
Because of whitespace and line break sensitivity you can't dynamically
generate serialized CoffeeScript (unless delicately handled) because it won't
compile.

~~~
noamsml
Why would you even do that? You could just dynamically generate serialized JS
and load it with CoffeeScript.

~~~
dstein
[http://en.wikipedia.org/wiki/Reflection_%28computer_science%...](http://en.wikipedia.org/wiki/Reflection_%28computer_science%29)

------
btipling
Ugh, there is nothing wrong with JavaScript, please let's all just forget that
CoffeeScript even exists. Thank you.

------
Almaviva
I don't find an overly naive use of recursion that leads to an exponential
time algorithm to be beautiful.

------
jergosh
aka "How not to implement Fibonacci sequence"

~~~
larelli
Y U no cache the results?

