The thing about CoffeeScript is that it makes it a ton easier to reason about doing operations like default arguments, pattern matching or expressive for loops. When you don't see the messy code generated from its syntactic sugar, you don't think its a problem. But when it comes to best practices, long term decisions and performance, CoffeeScript will stab you in the back.

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

Someone might write the function like that so that it would fit on one line and be easier to call. But as it turns out, there is a lot more than meets the eye. This is the generated code:

    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;
    };

Which in that case, you might as well skip CoffeeScript's for loop and do an ES5 `Array.protocal.map` call, which will do the same thing, and can be optimized a lot further by the engine.

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

Which, in V8, can be shortened down to:

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

That skips the whole array generation part and is much more concise and up to ES5 standards. But there are still a few more problems with the code. Look at what it generates:

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

See a problem? We could skip the entire first two lines by calling `Array.prototype.map` directly on the arguments. But also, we've forgotten that we never needed to 'map' over the array in the first place, because we know that `console.log` will return `undefined`. I just stuck with using map over `.forEach` so it would match CoffeeScript's 'always return something' rule, and it would be ugly to have an empty handing `return` at the end. So instead, we should probably write the function like so:

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

This is all in all the best of all the other code, because it generates the optimal representation in JS. If you wrote code like what CS generates, then you could see and make out a ton of flaws before hand, but who dare questions the power of CS and inspects the generated code? But none the less, if you were to write your CS like that, there would be no point in CS. Still, if you wanted to cleanest possible code to be generated, you'd need to put one of those annoying empty returns at the end of the function.

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