Top 3 things tl;dr

Paren-free chaining (think jQuery or d3):

    bar = svg.append 'rect'
      .attr 'fill', 'papayawhip'
      .attr 'width', width
      .attr 'height', 0
      .attr 'y', height
      .attr 'data-hover', data.slug

    [first, ..., last] = arrayOfStuff

    lastArgumentFn = (..., last) -> last

  1.6.3  real    0m2.287s
  1.7.0  real    0m1.655s

  arr = [1, 2, 3]
  [..., two, three] = arr

  myFun = (..., cb) ->
    cb()

  # disallowed
  [..., whatAmI, ...] = [1, 2, 3, 4]

https://github.com/jashkenas/coffee-script/pull/3193

[0] - https://github.com/jashkenas/coffee-script/blob/master/src/g...

http://coffeescript.org/documentation/docs/grammar.html

Personally I moved to LiveScript as it gives me much more syntactic support for functional semantics, without requiring runtime support like ClojureScript (although I'm looking into ClojureScript as well, just not using it in production). But I'm in a privileged position because I could make that choice myself; I think not many people could do this. And they don't, which means if they switched to CS they're effectively stuck with it for some time.

Which, yes, makes CoffeeScript rather mainstream language :)

In my opinion LiveScript is as similar to JS as Coffee is, just where CS adds syntactic support for more imperatively and OOP oriented constructs LS focuses on functional and declarative ones. Which are all expressible in JS.

Actually "different" would be ClojureScript, Amber or Objective-J. Or any number of compile-X-to-js projects.

Hip? Dunno, I moved onto ClojureScript years ago. ;)

I'm not so sure about that. I use it as an experienced JS developer because it makes a lot of needlessly complex JS operations simpler.

Most of those are features in ES6, so it may well go out of vogue then - I've played around a little and may well end up returning to JavaScript at that point.

The original reason for hatred towards CS in the Node community was when module written in CS started showing up on npm. If someone was trying to debug something and hunt down a problem to your module, they can't really read the code generated by CS(because it really does become a mess unless you don't abuse the syntactic sugar), and you can't debug the CS code.

Another problem occurs when you're trying to setup a sane build system for your project. It can become really tedious to use the entire build system every time you want to run your code, and even more to setup everything correctly with source maps, stack traces, minifying, etc. Just about every other module that deals with the code you write will support CS, so in many cases it is the deciding factor in which modules or libraries to use.

The original reason for me to dislike CS was because the first team I worked with using CS made so many different style choices about the code that it become unreadable. Some people wanted to use the syntactic sugar sparingly, others would use it and put everything in one line.

Take this for example:

    # print all lines given
    pall = (lines...) -> console.log line for line in lines

    var pall,
      __slice = [].slice;
    
    pall = function() {
      var line, lines, _i, _len, _results;
      lines = 1 <= arguments.length ? __slice.call(arguments, 0) : [];
      _results = [];
      for (_i = 0, _len = lines.length; _i < _len; _i++) {
        line = lines[_i];
        _results.push(console.log(line));
      }
      return _results;
    };

    # print all
    pall = (lines...) -> lines.map (line) -> console.log(line)

    # print all
    pall = (lines...) -> lines.map console.log

    var pall,
      __slice = [].slice;
    
    pall = function() {
      var lines;
      lines = 1 <= arguments.length ? __slice.call(arguments, 0) : [];
      return lines.map(console.log);
    };

    # print all
    pall = -> Array::forEach.call arguments, console.log

    pall = -> Array::forEach.call arguments, console.log
              return

  pall = (lines...) ->
    (console.log line) for line in lines
    return

  pall = -> console.log line for line in arguments; return

One can be annoyed by `return` in tail position, or delighted by invocations-as-expressions. But not both. It's ok to choose the latter. :-)

Also, `console.log` is not a fit for map, forEach, et al. Check the parameters.

This is FUD. CoffeeScript is JavaScript, and if you come into CoffeeScript thinking it works like ruby just because it looks like ruby then you're in for a rude awakening.

Personally, I'm a fan of CoffeeScript's streamlined syntax compared to JavaScript.

For example:

  describe 'when the universe exists', -> 
    it 'should be active', -> 
      expect(universe.active).toBe true

  describe('when the universe exists', function(){
    it('should be active', function(){
      expect(universe.active).toBe(true);
    });
  });

    describe 'syntax after upgrading', ->
      it 'should be even meatier', ->
        expect parentheses.required
          .toBe false

  describe 'when the universe exists' {
    it 'should be active' {
      universe.active should be true
    }
  }

I'm not sure about that; it prevents many of JS's ugly quirks: http://arcturo.github.io/library/coffeescript/07_the_bad_par... ;)

> Cleaning up the class model is generally not a good thing, since JavaScript isn't designed to have true OOP principles.

I really don't understand this. What does "true OOP principles" mean? Objects are so central to JavaScript that it has a concise syntax for object literals. It even goes to the extent of having a dynamic "this" to let any function work as a method in an object.

It has its rough edges (like primitives), yes, but they don't make it a non "true OO" language (whatever that means) IMO.

> [...] it's expressive for loops [...] shun people from using ES5 array methods like .forEach, .map, and .filter, which are a lot cleaner and more optimizable by the engine.

Thay are cleaner in the compiled JS, but Coffee's for loops are quite clean too, and they don't require a nested closure ;)

And, although i would also like native Array#forEach et al to be faster than manual for loops, that hasn't been the case in modern JS VMs: http://jsperf.com/for-vs-foreach/75

Speed and ease of development! Yes it is mostly syntactic sugar, where I wanted to make a point is that this "sugar" adds more to the language than sweetness for the sake of it. It exposes beautiful pattern that are cluttered in day to day javascript syntax. My final compiled javascript code is not the same I would have produced would I have coded directly in Javascript. Coffeescript also gives me a different approach to think about a problem.

> Things like it's expressive for loops and default arguments generate really ugly code, and shun people from using ES5 array methods like .forEach, .map, and .filter, which are a lot cleaner and more optimizable by the engine.

I use underscore which will delegate to .forEach et all it they exist... I really rarely use loop comprehension, though they can be very expressive if used correctly..

> CoffeeScript will completely obscure the way JavaScript works to newcomers

I disagree. I've installed the proper plugin (I'm on emacs, same is true for vim, sublime or lightTable), I am therefore two stroke away from the compiled javascript. Furthermore, I spent a decent amount of time a week in the debugger where the code is in JS. If I could have disliked this in the beginning, having two different languages whether you code or debug can seem unfamiliar, I actually love it. It keeps my Javascript sharpen and it gives a thorough understanding of exactly what's happening in my Coffeescript code. And that's exactly where I found a niche for Coffeescript. In my opinion, it is definitely not a replacement for Javascript, it is a cleaner, more expressive and easier way to write it, without any real overhead. Honestly, it took me minutes to understand and less than a day to feel comfortable and be efficient in Coffeescript. What I recommend to newcomers is to use coffeescript's syntax to to learn Javascript, by continually compiling down to JS and understanding what's happening. The JS output by CS isn't ugly at all, and that is a strong point. It is really possible to learn some great javascript idoms just by applying built-in coffeescript construct and understanding their value and working in JS

> JavaScript isn't designed to have true OOP principles

... Hmm right... ?

Ruby: _why hates you, and you're all just ghetto anyway

Nodejs: he and she are bad words.

Personally, I enjoy it and have been using it to build a fairly large Angular application (Java backend, oddly enough.) I've found that Coffee and Angular complement each other nicely.

I used it for a while, on a large project, and eventually came to hate it. I try to write as clean code as ppossible but still found the resulting mess of words, commas and arrows floating around at differing indentation levels to be much harder to read.

To me, even though javascripts syntax can be annoying, it's parentheses provide a certain amount of structure to the code.

That being said, I could never get over adding yet another additional layer of abstraction on scripted code that wasn't that bad to begin with.

Hell, I'm still waiting for Array::map to be dependable.

Ultimately though, wouldn't you want to use a js preprocessor that lets you write full spec ES6 and compiles down to ES4 or whatever your runtime target is? That's available today, and it doesn't confuse the meaning of class, fat arrow, variable scoping, etc.

But now that decent alternatives with support for static types like Typescript and Dart exist, I'd choose either one over Coffee just for maintenance reasons and improved tooling support.

http://www.google.ca/trends/explore?q=coffescript#q=coffescr...

https://gist.github.com/davidbanham/8678004

    api.get 'comments/1'
    .then transformComment
    .then (comment) ->
      appendwithEvents comment, 'click'
      cacheComment comment
    .fail console.error

I feel like this is an important improvement, but I don't really understand what it means. Can someone elaborate on what this means and how it works? How did things used to be different?

  result = range 1, 3
    .concat range 4, 6
    .map (x) -> x * x
    .filter (x) -> x % 2 is 0

  $('body')
  .click (e) ->
    $('.box')
    .fadeIn('fast')
    .addClass '.active'
  .css 'background', 'white'

  result = range(1, 3)
    .concat(range 4, 6)
    .map((x) -> x * x)
    .filter (x) -> x % 2 is 0

    result = range(1, 3).concat(range 4, 6).map((x) -> x * x).filter (x) -> x % 2 is 0

    result = range 1, 3
    result = result.concat range 4, 6
    result = result.map (x) -> x * x
    result = result.filter (x) -> x % 2 is 0

>When requiring CoffeeScript files in Node you must now explicitly register the compiler. This can be done with require 'coffee-script/register' or CoffeeScript.register(). Also for configuration such as Mocha's, use coffee-script/register.

Since I have not been specifying my CoffeeScript version, I have a feeling this update is going to break a lot of my Node.js code. Am I right?

    ###*
    # Test
    ###

    /**
     * Test
     */

    /**
    # Test
    */

One reason this is useful is if you want an array to wrap around. With modulo, you just index on `index % length` and all is well. But with remainder, this will only do what you want for `index >= 0`, because it can give negative outputs, given negative inputs.

In previous versions `//` compiled into an empty regular expression – something a little more difficult to express in JavaScript. But also something pretty much useless — hence the willingness to use it as an operator here.