Coffeescript作為Javascript低調的小弟實在是有過人之處，使用它可以增進開發效率，減少程式碼錯誤， 關鍵是能大幅提升開發愉悅感。我越來越覺得只要可能就在自己的專案中把coffee用起來。
然而也許你和我一樣，在了解完coffeescript的語法後準備一試身手的時候，卻面對如何把它引入項目而犯起愁來。
像老闆一樣指揮你的程式碼
CoffeeScript提供了一堆酷斃了的陣列迭代方法。最好的事莫過於這不僅能工作於數組，還能工作於jQuery物件了。來行詩一般的程式碼吧：
formValues = (elem.value for elem in $('.input'))
這行程式碼將會翻譯為如下的Javascript：
var elem, formValues;
formValues = (function() {
var _i, _len, _ref, _results;
_ref = $('.input');
_results = [];
for (_i = 0, _len = _ref.length; _i < _len; _i++) {
elem = _ref[_i];
_results.push(elem.value);
}
return _results;
})();
老實說最初這樣寫程式碼確實讓人提心吊膽的，但是一旦你開始擁抱CoffeeScript的魔法時，你會愛上它的。
飛一般的方法綁定
在jQuery的回呼中使用"=>"將會大大減省你手動綁定方法到物件的麻煩。還是來看段程式碼吧：
object =
func: -> $('#div').click => @element.css color: 'red'
以下是編譯輸出的Javascript：
var object;
var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; };
object = {
func: function() {
return $('#div').click(__bind(function() {
return this.element.css({
color: 'red'
});
}, this));
}
};
程式碼中的@element指向了一個jQuery的對象，該物件是在其他地方指定的－例如object.element = $('#some_div').
任何使用"=>"所指定的回呼函數都會自動綁定到原來的物件上，沒錯，這很酷。
在2011年函數是這樣呼叫的
瞅一眼這個：
$.post(
"/posts/update_title"
new_title: input.val()
id: something
-> alert('done')
'json'
)
使用CoffeeScript，多個參數可以寫成多行來調用，逗號和大括弧是可選的，這使得一些jQuery中籤比較長的方法比如$.post() 和$.animate() 等更加易讀。這兒還有一個例子：
$('#thing').animate
width: '+20px'
opacity: '0.5'
2000
'easeOutQuad'
很美味的Coffee不是嗎?要注意第一個參數是一個匿名的對象，你甚至可以省略調用函數的元括弧。
讓初始化來的更性感吧
我最初開始使用jQuery時我是這樣做頁面初始化的：
$(document).ready(function() {
some();
init();
calls();
})
CoffeeScript和新版的jQuery讓上面的程式碼進化的如此性感：
$-> some() init() calls()
函數定義語法在CoffeeScript裡本身已經非常酷了，能在上面這些場合使用使得其更酷了。你會發現所有需要回呼的函數呼叫在CoffeeScript中都是如此簡單。
其實coffeescript這種語言因其可以一對一地翻譯為javascript的特性，使用起來其實非常靈活。 將其引入項目的方式也不止一個。這裡，我先就node專案引入coffeescript的方式作一個匯總，並比較一下各個方式的優劣性。
直接使用coffee指令執行純coffeescript專案
一般提起coffeescript，自然而然地會想到他是javascript的小弟，總脫離不了js的陰影。其實你完全可以把它認定為獨立的語言。 我們都知道，在node平台上全域安裝完coffee-script包後，就可以透過coffee指令進入coffeescript的互動介面， 叫它repl也行。如果你的專案完全是用coffee寫的，那就簡單了，直接對你的入口腳本使用coffee指令就結了， 例如你的入口腳本名為“app.coffee”，那就執行：
coffee app.coffee
注意，这里的扩展名coffee是不能省略的。
这个方式应该说是使用coffeescript最“官方”的方式。简单，直接！而且，一旦你以一个coffee文件作为项目的入口， 那整个项目就同时兼容coffee和js了。你在项目里可以任意require js或coffee文件及模块， 甚至可以在项目中的js文件中随便require coffee文件。并且在你引用无论是coffee还是js文件的时候都无需扩展名， 只要前面部分名称不冲突就行。
这个方式有个最大的问题就是，如果它作为一个模块，只能被用于coffee项目；如果他作为一个应用， 运行环境必须安装coffee-script。毕竟coffeescript现在还是一个小众语言，它作为模块时丧失了js用户实在可惜。
另一个也许存在的缺点是性能方面的，毕竟node里面只有js引擎，coffee代码需要先编译为js再运行， 这个过程是要消耗一点点时间的，尽管coffee到js的编译速度其实挺快的。不过这应该不是什么大问题， 一般来说，require都是写在文件的顶部，也就是应用在启动的时候就一气儿把该require的文件都require了， require的时候coffee就被编译成了js放到了js引擎中，那么编译消耗的那点时间都集中在了应用启动时， 运行时几乎不会遇到require新的coffee的情况了。node最常见的使用场景是web服务器，这就更没问题了。
在javascript项目中引用coffeescript
npm中的coffee-script既可以全局安装，也可以作为项目的一个模块安装。那coffee-script作为项目的一个模块有啥意义呢？ 其实是给项目添加了一个coffeescript的编译器，这个项目就可以在运行时随时编译coffee文件。
你一定希望像第一种方式里那样随便引用coffee文件。没问题，只需要注册一下。假如你的项目入口文件是app.js， 那么只需要在这个文件最前面加上这么一句：
require('coffee-script/register');
然后你就可以在项目中随便require coffee文件了。
这个方式本质上和第一种方式没啥区别，只不过coffee-script没安装在全局，因此你的模块可以独立存在， 作为应用也不需要环境安装好coffee-script了。
缺点嘛，我觉得最大的问题就是容易让代码有些乱，一会儿js，一会儿coffee，当然第一种方式也可能会这样， 不过都用coffee启动了里面应该不会写js了吧……总之我觉得一个项目还是把语言统一起来比较好 （遗憾的是我主要用这种方式，在一个已经用js写出了大体结构的项目里，我就想用coffee肿么办……）
性能问题上跟第一种方式一样，不多说了。
正统的方式——编译
一说编译，就感觉回到了正儿八经的C或Java的时代。的确，作为一个编译型语言，编译后再运行才是正道。 c有gcc，java有javac，cofee有coffee -c。
要编译一个cofee文件很简单，比如要编辑app.coffee这个文件，就在文件的当前目录执行：
coffee -c app.coffee
一个名为app.js的文件就出现在当前目录下了。这个指令也可以应用于目录， 比如你把项目中所有的coffee源文件放到了src目录下，那就执行：
coffee -c src
src目录及其各级子目录下的所有coffee源文件都会编译成js文件，放到和源文件相同的目录中。
不过对于大型项目，把源文件和编译结果文件放到一起可不太好。指定一个输出目录就行了：
coffee -c -o outputs src
这个指令的参数顺序有点奇怪。在coffee的帮助里是这么定义的：
coffee [options] path/to/script.coffee -- [args]
注意，所有的选项（options）都在coffee和文件路径之间。而最后的args是把目标文件作为脚本执行时给传递的参数。 也就是说所有的选项都放在coffee和文件名之间就可以了。 而-c这个选项是单独的，没有自己的参数，它只表示要把指令最后面提供的那个文件给编译了，所以写成这样也行：
coffee -o outputs -c src
假如想再加个选项，让编译结果不被自执行函数体包围，就是：
coffee -o outputs -c -b src
再假如想把所有源文件编译成一个名为out.js的目标文件，就是：
coffee -o outputs -c -j out src
如果每次改点代码都要这么执行指令也挺烦人的。coffee指令有一个选项-w可以监视源文件的变动而自动编译：
coffee -o outputs -c -w src
對於大型專案來說，最好提前確定好編譯方式，讓所有開發人員只需要一個指令就搞定所有編譯的事情，這就需要自動化建置了。
offee提供了一個自動化建置工具，cake，就像c世界的make。 不過就像官網上說的那樣，cake是一個很簡單的建置系統。其實cake的功能就是執行一個名為cakefile的腳本， 而cakefile腳本是用coffeescript寫的。這個腳本只提供非常有限的內建函數，例如task， 用來宣告一個指令及其對應的描述和執行函數。其它的就是在寫一個純粹的node項目， 想完成編譯或使用node的fs模組輸出coffee模組編譯出來的字串， 要嘛用child_process模組來執行shell指令。其實cake建置的目標不一定必須是coffee，由於它實際上是執行一個node腳本， 處理任何自動化的事情都可以。
另外還有一些更優秀的第三方自動化建置工具也可以完成coffee的自動編譯，例如著名的Grunt，以及國內的fekit等。
這種正統的編譯方式也許是看起來最可靠的，應該深受老程式設計師的喜愛。它可以讓團隊形成固定的開發模式。 另外，編譯後的專案就成了純的js項目，無論是作為應用程式直接運作還是作為模組被別的項目引用都不需要額外的依賴。 而且執行時間不需要編譯，也就完全不存在編譯導致的效能問題了。
缺點嘛，就是太麻煩。如果你要做一個不太大的項目，光搞cakefile或設定grunt就要花半天時間，不太值得。
透過jQuery，node.js，javascript使用coffeescript的介紹，小夥伴們是否對coffeescript有了新的認識了呢
