[dustingetz]

he's missed the point. people aren't saying that "CoffeeScript is a priori somehow wrong or inferior or a bad choice". Coffeescript is an abstraction, and abstractions have potential to leak, so some people are questioning whether the benefits of coffeescript - namely, prettier code - are "worth it" for production-scale projects.

as your project gets big, does coffeescript help us write more maintainable code, better abstract our solutions so we can keep less things in our head at once, resulting in higher agility and fewer bugs? When you look at the deep reasons why a large codebase went sour, you're not blaming it on things like list comprehensions, you're blaming it on things like "Java strong-arms us towards building abstractions with only OOP, which over the course of a few years builds into indecipherable layers of implementation inheritance, causing high defect rates and much decreased agility".

The difference between CoffeeScript and Javascript, in terms of what a team can accomplish, hasn't been proven in production-scale projects. they may be, or maybe only for some teams, or maybe they aren't, but you can't debate something without being able to articulate the opponent's position.

update: interestingly, ClojureScript may be a language where the productivity delta from javascript is much larger, and is better worth it. clojurescript introduces new ideas and idioms to the js community, where coffeescript is an incremental update to javascript with no new ideas.

[_harry]

Anecdotally, Airbnb's mobile website (http://m.airbnb.com) was written entirely in CoffeeScript.

We had never used CoffeeScript before the project and we finished what you see today in about 6 weeks with a team of 3.

The project codebase looks like it was written with consistent style all the way through, which can be harder to do with JavaScript when it's 3am and all you want to do is make it work (when you start to get lazy). It was nice knowing that the for loops I was writing would compile to the same for loops that the other guys were writing.

CoffeeScript currently makes up just over 1% of Airbnb's codebase. I expect that number to grow quite a bit over the next year. Here's the breakdown according to github: http://cl.ly/2A241Z2d2I2m2R211Q1t

[roopeshv]

also, the comparison of number of lines for coffeescript and javascript is usually misleading, because same logic/implementation in cs is usually(or, always) smaller than the js version.

How much functionality, if you can make a guess, would you say is there in the codebase in cs?

[_harry]

All of the http://m.airbnb.com functionality is in CoffeeScript.

[focusaurus]

I think programmer productivity is also linked to happiness given one's own tools. My experience thus far is I'm happier when working with CoffeeScript. Not "OMG P0nies" happier, but significantly happier. I think the amount of boilerplate CS removes is significant, but indeed whether it is worthwhile depends on many factors in any given situation.

Given how CS maps to JS, I'm not too worried about leaky abstractions.

[dustingetz]

> programmer productivity is also linked to happiness given one's own tools

so i certainly agree with this, but in my experience, as the problems get harder, my happiness isn't determined by syntax.

the things that make me mad are "i have to fix this defect but this code is a fragile mess which i'm afraid to touch, so i bandaid on more hacks to have the minimum possible area of impact so i know for certain that i can give this to the client and it won't make things worse". that makes me fucking furious, man, the artist in me dies a little bit every time I do it. We have this issue in our large javascript codebase. CoffeeScript would probably help a little bit, but a speculative 2x improvement in "fucking furious" is still furious.

This opinion is probably along the lines of those who think CoffeeScript is a toy. List comprehensions don't fix our problem; we (my team) just don't care. investing in education, growing the teams ability to craft well factored code and stable code, that will have exponential payoff.

Now you can get meta here and say a language like ClojureScript which brings Clojure's strong opinions about managing complexity and crafting good abstractions - you get better just by using it, its sort of self-educating. ClojureScript has my attention.

[mistercow]

I would also argue that even if the abstraction overhead of CoffeeScript proves problematic in the long run, it would still be an excellent tool for writing out a functioning sketch of your project. The individual components can then, if needed, be rewritten in JS. And because of CoffeeScript's golden rule, that's a wonderfully simple process.

[mistercow]

> people aren't saying that "CoffeeScript is a priori somehow wrong or inferior or a bad choice".

It may not be the best anti-CoffeeScript argument out there, but it is a pervasive one. The most common objection I've seen to using CoffeeScript is not any actual criticism of the language or of the various overhead created by another layer of abstraction, but simple horse laughs along the lines of "CoffeeScript is a toy. Use a real language."

While the stronger arguments should be addressed, like the one against against adding an additional abstraction, I don't think addressing the weaker arguments is "missing the point".

[stdbrouw]

There is no point, it is a description of how some people respond to language innovation. I've seen people reject CoffeeScript for valid reasons (even if I don't share them), but I have definitely also seen people show a knee-jerk aversion to CoffeeScript without even really knowing what it is, thinking it is somehow "wrong" on a fundamental level.