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):
- 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
Almost a year later, it’s worth posting some updates:
- 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.
- 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
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)
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