[untog]

CoffeeScript was designed for non-JS coders to feel a lot more comfortable writing JS.

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.

[L8D]

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

[jacobolus]

Actually, the original version, something like:

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

Is going to get you much better performance in JavaScript than using the forEach method.

[nickfargo]

Pretty big rush to judgement. Slice off a copy of the arguments if you need them, but

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

would have done just fine there.

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.

[smrtinsert]

Much ado about nothing. CoffeeScript performance in general is a lot better due to non emulated foreach constructs which plague javascript today. Like noted there are ways of teasing the compiler in generating very friendly looking js code, but honestly if you are tripped up by a simple for loop in coffeescript maybe looking at code isn't your cup of tea.