而來到CoffeeScript的世界，美妙故事再次上演。在寫了幾行代碼后我相信你將不會再想念原生的Javascript了。CoffeeScript包含了許多新特性，當將它與jQuery，node.js,javascript結合時，你會發現一片新天地。

Coffeescript作為Javascript低調的小弟實在是有過人之處，使用它可以增進開發效率，減少代碼錯誤， 關鍵是能大幅提升開發愉悅感。我越來越覺得只要可能就在自己的項目中把coffee用起來。

然而也許你和我一樣，在了解完coffeescript的語法后準備一試身手的時候，卻面對如何把它引入項目而犯起愁來。

像老板一樣指揮你的代碼

CoffeeScript提供了一堆酷斃了的數組迭代方法。最好的事莫過于這不僅僅能工作于數組，還能工作于jQuery對象了。來行詩一般的代碼吧：

1. formValues = (elem.value for elem in $('.input'))  

這行代碼將會被翻譯為如下的Javascript：

1. var elem, formValues;  
2. formValues = (function() {  
3. var _i, _len, _ref, _results;  
4. _ref = $('.input');  
5. _results = [];  
6. for (_i = 0, _len = _ref.length; _i < _len; _i++) {  
7. elem = _ref[_i];  
8. _results.push(elem.value);  
9. }  
10. return _results;  
11. })();  

老實說最初這樣寫代碼確實讓人提心吊膽的，但是一旦你開始擁抱CoffeeScript的魔法時，你會愛上它的。

飛一般的方法綁定

在jQuery的回調中使用"=>"將會大大減省你手動綁定方法到對象的麻煩。還是來看段代碼吧：

1. object =  
2. func: -> $('#div').click => @element.css color: 'red' 

下面是編譯輸出的Javascript：

1. var object;  
2. var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; };  
3. object = {  
4. func: function() {  
5. return $('#div').click(__bind(function() {  
6. return this.element.css({  
7. color: 'red' 
8. });  
9. }, this));  
10. }  
11. };  

代碼中的@element指向了一個jQuery的對象，該對象是在其他地方指定的——比如object.element = $('#some_div').

任何使用"=>"所指定的回調函數都會自動綁定到原來的對象上，沒錯，這很酷。

在2011年函數是這樣調用的

瞅一眼這個：

1. $.post(  
2. "/posts/update_title" 
3. new_title: input.val()  
4. id: something  
5. -> alert('done')  
6. 'json' 
7. )  

使用CoffeeScript，多個參數可以寫成多行來調用，逗號和大括弧是可選的，這使得一些jQuery中簽名比較長的方法比如$.post() 和 $.animate() 等更加易讀。這兒還有一個例子：

1. $('#thing').animate  
2. width: '+20px' 
3. opacity: '0.5' 
4. 2000  
5. 'easeOutQuad' 

很美味的Coffee不是嗎?要注意第一個參數是一個匿名的對象，你甚至可以省略調用函數的元括弧。

讓初始化來的更性感吧

我最初開始使用jQuery時我是這樣做頁面初始化的：

1. $(document).ready(function() {  
2. some();  
3. init();  
4. calls();  
5. })  

CoffeeScript和新版的jQuery使得上面的代碼進化的如此性感：

1. $->  
2. some()  
3. init()  
4. calls()  

函數定義語法在CoffeeScript里本身已經非?？崃耍茉谏厦孢@些場合使用使得其更酷了。你會發現所有需要回調的函數調用在CoffeeScript中都是如此簡單。

其實coffeescript這種語言因其可以一對一地翻譯為javascript的特性，使用起來其實非常靈活。 將其引入項目的方式也不止一個。這里，我先就node項目引入coffeescript的方式作一個匯總，并對比一下各個方式的優劣性。

直接使用coffee指令運行純coffeescript項目

一般提起coffeescript，自然而然地會想到他是javascript的小弟，總脫離不了js的陰影。其實你完全可以把它認作是獨立的語言。 我們都知道，在node平臺上全局安裝完coffee-script包后，就可以通過coffee指令進入coffeescript的交互界面， 叫它repl也行。如果你的項目完全是用coffee寫的，那就簡單了，直接對你的入口腳本使用coffee指令就結了， 比如你的入口腳本名為“app.coffee”，那就執行：

1. 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， 那么只需要在這個文件最前面加上這么一句：

1. 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這個文件，就在文件的當前目錄執行：

1. coffee -c app.coffee 

一個名為app.js的文件就出現在當前目錄下了。這個指令也可以應用于目錄， 比如你把項目中所有的coffee源文件放到了src目錄下，那就執行：

1. coffee -c src 

src目錄及其各級子目錄下的所有coffee源文件都會編譯成js文件，放到和源文件相同的目錄中。

不過對于大型項目，把源文件和編譯結果文件放到一起可不太好。指定一個輸出目錄就行了：

1. coffee -c -o outputs src 

這個指令的參數順序有點奇怪。在coffee的幫助里是這么定義的：

coffee [options] path/to/script.coffee -- [args]

注意，所有的選項(options)都在coffee和文件路徑之間。而最后的args是把目標文件作為腳本執行時給傳遞的參數。 也就是說所有的選項都放在coffee和文件名之間就可以了。 而-c這個選項是單獨的，沒有自己的參數，它只表示要把指令最后面提供的那個文件給編譯了，所以寫成這樣也行：

1. coffee -o outputs -c src 

假如想再加個選項，讓編譯結果不被自執行函數體包圍，就是：

1. coffee -o outputs -c -b src 

再假如想把所有源文件編譯成一個名為out.js的目標文件，就是：

1. coffee -o outputs -c -j out src 

如果每次改點代碼都要這么執行指令也挺煩人的。coffee指令有一個選項-w可以監視源文件的變動而自動編譯：

1. 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有了新的認識了呢