Edit: I wrote about some of my favorite features of CoffeeScript when we added CoffeeScript support to our CMS app HiFi... http://www.gethifi.com/blog/hosted-cms-coffeescript-support

tl;dr:

1) Lightweight function declarations (with default values!)

2) Implicit Returns

3) Everything is an Expression

4) Object Literal YAML-like syntax

5) Simple, Classical OO Features (you don't have to use them and can still directly access prototypal features, too)

6) (Not in the post) Binding 'this' to the scope's 'this' using => is awesome.

Debugging has not been a problem for me yet, the generated JavaScript is very clean and easy to navigate.

That being said, I'm a Python fan, so I consider significant whitespace to be a feature, not an irritant.

Later I opened the file on Windows (Notepad++) and saw that one line had not been indented, which wasn't showing up on Vim/Gedit. I never tested it to see if that was indeed the problem, I'd already moved on.

    if one
      if two
        two
    oops
      one

    Parse error on line 4: Unexpected 'INDENT'

Since the compiled JS is just-the-code-I-wrote-myself only in a slightly more verbose curly syntax, troubleshooting my own CS code even when compiled in JS is totally not an issue. Thankfully Coffee does not minify or otherwise obscure the code.

Alas, poor error messages are a big -

    # vim: ts=2 sw=2 et :

  set listchars=tab:»·,trail:·
  set list

Regardless, with coffee being default in Rails 3.1, I'm sure editor support will show up quickly. For the time being though, I just stumbled onto this: https://github.com/kchmck/vim-coffee-script (have not tried it myself).

The tabstop variable sets the ratio of tabs to spaces (in this case, one tab is equivalent to two spaces).

The shiftwidth variable controls how much a line gets moved when it gets "shifted". In VIM pressing << in Normal mode on a line does a left shift. With a shiftwidth of two, it will move it over two spaces to the left. >> is right shift. There are many more ways of shifting, however.

The expandtab option sets it up so that every time you hit the tab key, VIM will insert the equivalent number of spaces according to the tabstop. In this case, pressing tab will give you two spaces.

then someone else would say that it's a shame that TABS aren't supported and that it would have been so easy for the language designer to support them. I'm sorry if it sounds snarky, but I find it arrogant to assume that design decisions are "easy" simply because they look easy to implement.

  gg=G:retab!<CR>

[1] http://metaphysicaldeveloper.wordpress.com/2011/03/31/354/

The CoffeeScript documentation is a fantastic exposition of that: http://jashkenas.github.com/coffee-script/

Truth is, it's borrowed from both, and other languages besides, to synthesize a gorgeous syntax which is really its own.

First of all, I'd like to point out that syntax is not entirely irrelevant, at least not in the sense that CoffeeScript is "just a weird syntax" for JavaScript. Python decorators and list comprehensions are generally thought of as very nice features of the language, but they're really just a nice syntax for higher-order functions and iteration. That syntax makes a big difference. Just adding CoffeeScript's syntax for functions (including the do-operator) and the existential operator would noticeably reduce the size of most JavaScript code, without anything else.

But the difference isn't just syntactic. Here are a few semantic changes in CoffeeScript:

• Everything is an expression (a la Ruby)

• Equality is always strict

• A simplified class-based inheritance model on top of JavaScript's prototypal inheritance

• Switch is almost identical to Ruby's case expression rather than C's switch statement (i.e. clauses don't fall through and it's an expression rather than a statement), which makes it much more useful

I'll put it this way: I've been making websites since 1995 and am fairly proficient in JavaScript, but I have never really liked the language all that much. But CoffeeScript is a joy to use. I actually enjoy programming it, and it's just amazingly readable (both from the nicer syntax and the fact that CoffeeScript's sugar means you don't have to write as much code, and it's easier to understand five lines than 20, even if 15 of the 20 are boilerplate).

Very realistic. Looking at the compiled CoffeeScript taught me more Javascript than all of the tutorials put together, and CoffeeScript itself was a joy to learn. I think you're under estimating your own baby here, jashkenas.

I would point out that you're not so much 'skipping' learning JS, as that learning CS is the quickest way I've found so far to learn JS.

I'm just saying that you're not in any way going to avoid learning JS by starting with Coffee -- you still need to know:

  * How JS numbers work.

  * All about "this" (dynamic scope).

  * Function vs. block-level scope.

  * How the prototype chain is structured.

The other option is to skip learning javascript properly, which I tried... and it came back hard at me when I tried going beyond enhancing my pages with jquery.

It's what I did. Since I'm already comfortably with Ruby and CoffeeScript's simple syntax, I used CoffeeScript's "Try CoffeeScript" console to insert Ruby-like code and get the Javascript equivalent. Helped me rapidly map Ruby-Javascript equivalences in my head.

Now that I'm quickly comfortable with Javscript's surface and my foot's in the door, diving deeper into the language isn't the obstacle I used to consider it as.

edit: Well listen to the man himself, but I learned tons about JS's semantics by picking up (and picking apart) CS.

Also it's class system and function binding (=>) is something I feel I can no longer live without.

How does coffee script play with existing object oriented JS libraries? Is there compile-time type checking?

https://code.google.com/closure/compiler/docs/js-for-compile...

To misquote the "Pragmatic Programmer" book... don't use wizard code you don't understand. The opposite applies in my opinion.

Life won't get better if interacting with the rest of the world becomes headachery, but thankfully the products in question aren't too hostile to rest of the world. There isn't much of an impedance mismatch between CSS and Sass and following the generated code is easy.

From what little I have written of Coffeescript, it generates clean Javascript and should be easy to follow for anyone who knows Javascript. It's not lifechanging per se but there are things which are much more elegant in Coffeescript.

1) Convenient 'this' binding using =>

2) Lexical scoping. Not much of an issue since I use the 'var' keyword all the time; either that or window.foo or something similar depending on what I am trying to do.

3) I have coded in Python and the "mandatory indentation sans braces" is something I am used to and appreciate. It makes the nested event handling calls prettier.

4) I don't need to use underscore.js while using Coffeescript. The language has some essential feature built-in.

5) The existential operator. From the docs:

"It's a little difficult to check for the existence of a variable in JavaScript. if (variable) ... comes close, but fails for zero, the empty string, and false. CoffeeScript's existential operator ? returns true unless a variable is null or undefined, which makes it analogous to Ruby's nil?"

6) String iterpolation, here docs.

Best of all, there are fewer lines of code to make mistakes in. And fewer stupid "forgot a semicolon" problems.

I'd suggest that people also look at Underscore.js (http://documentcloud.github.com/underscore/) and Backbone.js (http://documentcloud.github.com/backbone/). Same authorship, same quality code, great ideas, great execution.

  <script language="coffeescript">

http://jashkenas.github.com/coffee-script/#scripts

* You have to include the "coffee-script.js" compiler file, which is medium large (mostly the generated parse table).

* It's harder to debug, because you're debugging through an eval(), without the compiled JavaScript handy.

Those two caveats aside, it works fine. All of the interactions on the CoffeeScript.org homepage are powered by it.

If you like Sass, you should check out Stylus. Similar, but better. http://learnboost.github.com/stylus/

    CSS looks like Assembly code ... you could 
    write it... but you'd need a damn good reason to

That said, I can live without the improved CSS features. When I'm working on design-stuff, what really gets in my way is the lack of talent.

As for CoffeeScript, the language looks really interesting, but IMHO, it's just another tool that you need to add to an already HEAVY stack, another tool that breaks and needs special care from time to time, another tool to be learned.

And I'm not sure that CS is so life-changing. Does it fix browser incompatibilities for you? Does it optimize Javascript to run faster? Is it easier to debug? Does it have a kick-ass library that's optimized for it?

IMHO, syntactic sugar (without new paradigms) doesn't get you further than changing your text-editor / adding some newer snippets to it for the boilerplate.

I never understood the rationale behind this decision (does anyone prefer SCSS over SASS?), but who cares as long as SASS remains a first-class citizen.

The SCSS syntax works for me because it's like normal CSS but with extra useful features - functions, mixins, nesting, etc.

If I need to paste in some sample css from the web I just copy it to the clipboard and then:

    pbpaste | sass-convert | pbcopy

That means you can use that CSS file provided by the designer directly, and gradually improve it, or you can copy/paste examples given all across the web.

In some cases, that might be a good thing.

The point of CS is to optimize for developer productivity and happiness, so I think your questions are largely missing the point. It's like asking "well that's a good screwdriver, but does it hammer nails?".

The correct question to ask is: what do I get from this syntactic sugar, and what do I trade. Or to stick with our metaphor:

"What does this screwdriver bring to the table, and does it INTERFERE with the hammering of nails etc?".

So as stated, CS lets you write code faster, express yourself more clearly, and removes headaches common to Javascript. These headaches are problems that are largely not addressed by other tools like jQuery (which have different goals).

To answer your questions:

> Does it fix browser incompatibilities for you

Yes, but only in terms of the language. CS compiles to lowest common denominator Javascript, so you know the compiled code will run just about anywhere.

So you don't have to worry about whether or not the browser's JS engine supports list comprehensions, because you're using CS.

The question is not so much "Does it fix browser incompatibilities for you".... but "Does it introduce browser incompatibilities?". To that, the answer is no.

>Does it optimize Javascript to run faster?

CS allows you to write really expressive code that gets compiled down to simple (but verbose) forms. This has the side-effect that CS code will generally be faster than Vanilla JS code that is written with a similar expressiveness.

In Vanilla JS you would generally have to introduce a library to get the same expressiveness, and that has a run-time penalty. For example: Something that is compiled to a simple for-loop in CS would require a bunch of function calls in a library in vanilla JS, adding a lot of overhead.

CS is not a tool to optimize code, so asking if it optimizes code misses the point. The real question is whether or not it introduces inefficiency, because if it does....that's a drawback that needs to be contrasted to it's benefits.

In this case, no it doesn't...and the code it produces is sometimes faster than similar vanilla JS code.

>Does it have a kick-ass library that's optimized for it?

CS is not meant to fill the same role as a library.

The question is not "does it have a library"...but "what's the implications of using CS vis a vis libraries?" The answer is CS interacts with JS seamlessly, use any library you like.

>Is it easier to debug?

No, because that's not the point of CS. CS is not a debugging tool. The right question is: "is it harder to debug?".

Here we hit what imho is the only real trade-off involved in CS.

Some will hem and haw about having an explicit compilation step; but the tooling support for CS is great and any serious JS developer can fit it into their dev process seamlessly (via commit hooks, watch, build scripts, etc).

Debugging problems is a legit concern, but in my experience it does not add significant problems. Errors in CS syntax are generally caught during compilation and other errors can often be easier to find because the CS code is cleaner and it's easier to catch errors in logic.

I think beginners will often hit problems with debugging and CS because it adds a layer to confuse them. Experienced JS devs on the other hand should be able to cleanly separate the layers and debug them effectively.

The tooling for debugging CS in the future looks promising and will improve the situation.

As for your suggestion that you could just improve your text-editor, use macros, etc....I think that's a good tool to have in your belt but it just doesn't compare to what CS brings to the table.

Either you'd be duplicating CS's efforts ...or you'd not hit the same level of capability...

In the first case, it'd be a pointless re-inventing of the wheel, but your wheel would have drawbacks CS lacks.

With CS there is:

- Lot's of editor support. Your suggestion is tied to 1 editor.

- Lot's of tooling support. There is framework support, and possible browser support in the future...etc etc. Yours would have none, or would need it written.

- Widespread use. Lots of coders will understand my CS code right off the bat, or can learn it easily. Not only will no one understand your crazy macros etc, there's little incentive to learn them.

In the latter case, it's not a valid comparison.

The real question here is what does CS bring to the table, and what do you trade for it. CS had demonstrable benefits and demonstrable drawbacks.

It's my opinion that the benefits dramatically outweigh the drawbacks, but that's a question every developer must ask and answer for themselves.

I get that your contention is somehow, "well if it doesn't do these specific things, it's not 'life changing'", but that seems a pretty arbitrary line to me.

I don't see how you can say developer productivity is not a vital factor in development....and that something that improves productivity, readability, development speed, etc...is not "life-changing", at least as much so as the other factors you mentioned.

When judged in terms of what it's goals are, I think CS is highly effective and far from "pure syntactic sugar" (which to me implies something that simply saves typing).

    The point of CS is to optimize for developer 
    productivity and happiness.

CS doesn't have any new paradigms, the type system is the same as Javascript, scoping rules are the same, it's really nothing more than syntactic sugar over JS.

Even Ruby and Python have a lot more differences.

    well that's a good screwdriver, but does 
    it hammer nails

Personally I never understood why people use it to make a point.

I find sometimes you have to repeat yourself a lot before people will understand a point.

> That's a subjective claim that I also think is untrue.

It's obviously my opinion, and I can't speak for the developer....but it's fairly accurate.

To say it's "untrue" it's just plain wrong, and if you're going to suggest that it's "untrue", you should offer your opinion as to what is "true".

Anyway, it's perhaps a simplification and incomplete, but it's demonstrably true.

If you go and read the docs for Coffeescript and what the creator has said, here is the general point made:

- Coffeescript is designed to make Javascript easier and faster to write.

- Coffeescript is designed to reduce some of the headaches associated with Javascript, and make it more expressive.

Those are the immediate goals, but the reason behind those goals is to increase productivity. Increased productivity is WHY those things are desirable.

Nobody just wants to type more JS code per minute for no reason at all.

>CS doesn't have any new paradigms

Well for one, that's not entirely accurate.

For one, In CS everything is an expression, which is not the case in JS.

However, even if we were to grant that point...it's moot.

See, this is why I have to repeat myself. Although it seems despite debunking this misconception over and over you still managed to maintain it.

CS isn't meant to be the latest and greatest language, or exist in a vacuum. If that was the point, why implement it on top of Javascript and put so much effort into making it compatible with Javascript?

CS doesn't introduce new "paradigms" (at least the kind you are getting at) because that's not what it's FOR.

CS isn't supposed to exist independent of Javascript, it exists to generate Javascript.

The fact of the matter is, for some reason some people don't analyze technology based on objective reasoning about it's merits.

In the Javascript world, jQuery and Coffeescript are prominent victims of this.

There's lots of reasons to dislike jQuery....but by far people hate on it for reasons entirely removed from facts.

Same with Coffeescript.

Remarking that Coffeescript doesn't optimize code is a complete non-sequitur.

More importantly this stupid implication that "syntactic sugar" is somehow pointless.

Haters always make some smug implication about CS being "only syntactic sugar", as if that's some sort of actual critique or something.

What these people don't understand is:

Syntactic sugar is a method whereby languages are improved.

There's nothing wrong with syntactic sugar, and it is very much a powerful and useful thing.

I can write list comprehensions in Cofeescript....you can't do that in vanilla JS unless you want your code to only run on certain engines.

That is one example of the power of "syntactic sugar".

People get confused because they mistake it for simple examples of syntactic sugar where

bar (x, foo(x, y, z))

is created from: foobar( x )

In that case the transformation is useful, but so sleight it's questionable whether the effort is worth it.

...but that's not what we're talking about.

>This analogy holds only when you're talking about (a) a screwdriver + (b) a hammer, i.e. totally different tools, with totally different use-cases.

YES... and that is what we are talking about. At least it's sure what I'm talking about.

When you compare Coffeescript to things like:

- Libraries - Code optimizing tools - Debugging tools - etc

Those are totally different tools with totally different use-cases.

If I'm curt it's because I'm sick of this nonsense every time CS comes up.

There's a few people who make actually informed points either for or against it based on facts and technical merits...

...and thens there's a bunch of techno-hipsters who either put it down or blindly adopt it without knowing what they are talking about. (not saying you are in this group, but read the comments any time CS is mentioned and you will see this group)

    When you compare Coffeescript to things like:
    - Libraries - Code optimizing tools 
    - Debugging tools - etc
    Those are totally different tools with 
    totally different use-cases

And this has more to do with the capabilities of the runtimes, the introspection capabilities available, the available libraries, the debugging tools, the quality of the read-eval loop, the smartness of the compiler/VM to handle errors -- and a lot less to do with whether semicolons are optional.

You're trying to divorce these assets from the job of a programming language, or from the happiness experienced when using said language, but they are not divorceable, just as you can't separate a language from the compilers available (i.e. it's factually incorrect to say that languages themselves are not slow, as most languages in use have been influenced by known compiler/VM optimizations).

And my point about libraries does hold -- to use Rails, you need Ruby, and can't use it from Python because you would need a clone that's built for Python's capabilities, as while the type system is very similar, there are lots of differences (e.g. namespaces, scoping rules, decorators versus anonymous blocks, functions as first-class citizens versus Proc#call, mixins versus multiple-inheritance, method-dispatching itself, etc...).

But Javascript/CS are so similar that they can share libraries effortlessly. CS will never have the benefits of libraries, as those libraries will be usable from Javascript.

    If I'm curt it's because I'm sick of 
    this nonsense every time CS comes up

And truth is I couldn't care less if it is being adopted as a default in Rails. Heck, I've been proven wrong before, and it may actually work out for the best.

(:: Javascript : CoffeeScript) would be a bit of a stretch IMO)

With Rails these kinds of things (and other things like source layout and such) are just kind of taken care of for you. On the other hand, I'm having a blast doing some CoffeeScript + Node development.