Has anyone used Coffeescript for a production application?

Coffeescript looks pretty cool. Has anyone used it? What are its Pros & Cons?

We've started to use CoffeeScript in our product - a non-public facing website which is basically an app for browsing certain kinds of data. We use CoffeeScript as a command-line compiler (not on the server, which we'd eventually like to do).

PROS (for us):

• It gets rid of a lot of needless clutter in javascript (eg braces, semi-colons, some brackets) to the extent that the code is cleaner & easier to comprehend at-a-glance than javascript
• 20-30% less lines of code than javascript (to do exactly the same thing)
• CoffeeScript not only removes noise but adds keywords, classes, and features like heredocs to make coding cleaner and somewhat more enjoyable
• Given the previous points, it is undoubtedly faster to code in CoffeeScript once you learn the ropes

CONS

• When using the command-line compiler: to debug, you're looking at different code when solving the problem (javascript) as when writing the fix (coffeescript). However, somewhat unbelievably, our CoffeeScript is so awesome we've never needed to debug it!

Importantly, we can turn back at anytime. Our coffeescript compiler is just producing readable javascript, so if anyone changes their mind or can't figure something out, then we can just drop back to using the javascript that coffeescript produced - and keep coding.

We use coffeescript for all of the javascript in BusyConf. A large portion of BusyConf is a client side application that runs in browers, including support for offline mode.

All of our coffeescript code is fully tested. The tests themselves are written in coffeescript, and use the Qunit framework (which is written in javascript). We also wrote an extension to the Qunit framework that makes the tests nicer. The Qunit extension is written in CoffeeScript. Our application has a mobile version which is written in CoffeeScript, and it uses the Sencha Touch framework (which is written in javascript).

The take away from that is that you can freely intermix javascript dependencies in your application, but all of the code you write (your application code, tests, etc) can (and should!) be coffeescript.

Almost a year later, it's worth posting some updates:

1. Ruby on Rails 3.1 is incorporating official CoffeeScript support, which means it's going to see far more real-world use. I gave a talk at RailsConf last month, where most of the attendees hadn't heard of CoffeeScript before and—given dhh's strong endorsement—were eager to get into it.
2. There's a book on CoffeeScript, currently in eBook and soon to be in print from The Pragmatic Bookshelf. It's called CoffeeScript: Accelerated JavaScript Development, and it's by yours truly. It's based on CoffeeScript 1.1.1.
3. The language has actually changed very little in the six months between 1.0 and 1.1.1; nearly all of the changes qualify as "bugfixes." I had to make very few tweaks to the code in the book for the transition from 1.0.1 to 1.1.1. However, I'm sure the language will see more significant changes in the future.

The most definitive list of CoffeeScript projects is on the CoffeeScript wiki's In the Wild page.

I'd say that most of the production use of CoffeeScript so far is in conjunction with Appcelerator to create iPhone/Android apps. (Wynn Netherland of The Changelog blurbed my book by describing CoffeeScript as "my secret weapon for iOS, Android, and WebOS mobile development"), but there's going to be a lot more use in production Rails apps—and, I hope, elsewhere—in the coming months.

Coffeescript was used in the Ars Technica reader for iPad http://arstechnica.com/apple/news/2010/11/introducing-the-ars-technica-reader-for-ipad.ars

I really love Coffeescript these days. Essentially the entire HotelTonight iPhone application is written in it (using Appcelerator Titanium, which lets you write "native" apps in JavaScript - they are not web apps, say like Phonegap). I chose to use Coffeescript in this case because it makes organizing and maintaining a large amount of JS a lot easier. I also find it simply a lot more pleasurable to write code with Coffeescript (vs. JavaScript). We also use Coffeescript for the JS in our Rails app, but this is incredibly minor/small amount of code in relation to the entire phone app.

The pros mostly have to do with just being a nicer syntax, but also that it standardizes an OO mechanism, and then adds some nice additions (list comprehensions, some scope things, etc.).

The cons are almost zero for me. The primary one is that it's an extra layer to debug. You will need to look at the generated JS (which is VERY readable and nice), and then map that to your Coffeescript code. For us, this hasn't been an issue at all, but YMMV.

In the end, my take is, there is zero risk in terms of using it on a production app, so, don't let that be a blocker. Then, go try it out. Write some code with it, compare that to what you'd write in JS, look at the generated code to see if you are comfy with being able to read that for debugging needs. Also, hang out in the #coffeescript IRC, people are good there. And finally, see how it would integrate with your app, e.g. what's your "build" process (e.g. for Rails, try Barista, for something standalone, just use the included "coffee -w", etc.).

Coffeescript really just makes writing JS easier. You end up with cleaner, more efficient code.

That being said, you still can only do whatever you can do in vanilla JS. Once you use coffeescript enough, it does become a lot easier to write (good) JS.

So if you haven't used JS a ton, I'd suggest learning coffescript instead. You'll get better, cleaner, less buggy code. If you're already really fluent in JS, it might not be a good idea to start using coffeescript on a "real" app.

(Also, coffeescript does irk me a bit in that it seems to encourage rather "floofy" code. I don't know if it's a good thing or a bad thing, but it seems an extreme case of TMTOWTDI)

Note that although there is a compiler, you don't get static checking due to JavaScript's dynamic nature. As written in the FAQ:

> Static Analysis > > CoffeeScript uses a straight source-to-source compiler. No type > checking is performed, and we can't work out if a variable even exists > or not. This means that we can't implement features that other > languages can build in natively without costly runtime checks. As a > result, any feature which relies on this kind of analysis won't be > considered.

IDE support is less mature than that of JavaScript (Cloud9 has syntax highlight support, but Eclipse JSDT has refactorings and more): https://stackoverflow.com/questions/4084167/ide-or-its-add-in-for-coffescript-programming