A Case Against Using CoffeeScript

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript.

The rest of the examples, though, don't hold much water. The takeaway from them is "it's possible to write terribly-factored code, even in a pretty language".

    doSomething() if five and six and seven

Can be rewritten as this, if it's more comfortable for you:

    if (five && six && seven) then doSomething()

!=, &&, ||, (), and the like are still usable in Coffeescript. If it makes the code easier to read, then use them!

The whole concern with list comprehension syntax order is sort of a red herring - it works that way in Javascript 1.8, as well! In fact, nearly every language that implements list comprehension does it similarly. 160-column 1-liners are evil in any language, not just Coffeescript. If you don't like the "method, loop, condition" syntax of list comprehensions, that's a problem with list comprehensions, not with Coffeescript.

The points about the implicit returns and parentheses-less calls apply, as well. When it makes sense to explicitly use them for code clarity, use them.

For example, your confusing getUser method can be easily written as:

    getUser = (id) ->
      url = "users/#{id}"
      dfd = $.ajax(
        url: url
        format: 'json'
        method: 'get'
      )
      return { url: url, promise: dfd.promise() }

Voila, it's still coffeescript, and it's very readable, easy to understand, and not at all difficult to maintain.

The fat arrow, like the rest of the examples, is yet-another-case of "Yes, you can shoot yourself in the face with it, if you abuse it". Event binding isn't the only case when you need to preserve scope! Sometimes (frequently, even) you need to pass around an anonymous function bound to a specific scope. The fat arrow is explicitly for that sort of work. If you abuse it every time you could otherwise just call call() or apply() (because you have access to the scope to invoke the function on, in addition to the function itself), then yeah, it's bad.

Have you even looked at the implementation of $.proxy() used in your examples there? Guess what it does? It creates a new anonymous function, binds it to the passed-in scope, and returns it. Which is exactly what the fat arrow does in Coffeescript. Why is it evil in Coffeescript, but okay in jQuery? Because you aren't aware it's happening?

Your "This is how you should do it" method in Coffeescript is wrong. It should be something like this:

    widget =
      attach: ->
        @el.bind 'click', @handler
      handler: (event) =>
        doStuffWithThis()

That's clearer than any of your examples, Just Works, doesn't have a jQuery dependency, and is even less code than your corrected example. First-class functions have the `this` problem in every language, and the fat arrow is very nice syntactic sugar for what you have to do anyway.

The purpose of Coffeescript is to make your life as a Javascript developer easier. If you're using it to make your life harder, you're doing it wrong. It's not a case against using Coffeescript - it's a case against writing terrible code.

The debugging complaint is valid, but a) doesn't generally seem that troublesome in practice (especially given the still-crude state of JavaScript debugging tools in general), and b) will be a lot less valid in the near future, as WebKit, Google and Mozilla are all adopting support for alternative languages in their respective JavaScript implementations IIRC.

That is an opinion. I like that CoffeeScript allows me to have more choice over how I write my programs. If I want to write a piece of code in a different way, I can. If I don't think it will improve readability, I won't. You don't have to use all features of CoffeeScript all the time.

Plus, if you don't like it at all, just don't use it and quit complaining. :)

Exactly my point Issac. It feels great when you write it, but when you wake up in the morning...

We scan the left side of the code when reading. Checking the right side of the code to see if it actually will execute must invariably be slower. Also, the language encourages super long comprehensions.