Teambition是一家追求卓越技術(shù)的公司，我們工程師都很Geek，我們使用了很多新潮的，開源的技術(shù)。同時(shí)我們也貢獻(xiàn)了很多開源的項(xiàng)目。我們希望能夠把一些技術(shù)經(jīng)驗(yàn)分享給大家。于是有了這個(gè)「創(chuàng)作隨筆」。廢話休說，「創(chuàng)作隨筆」第一彈，來自我們的前端工程師寸志，談一談他在前端模塊化開發(fā)方面的一些感想。

在模塊化方面，Node.js就顯得游刃有余。

作為用戶，我們把代碼放到一個(gè)個(gè)JavaScript文件中，然后Node.js就有一套規(guī)則幫我們把這些代碼組織起來，Node.js還有包的概念，于是我們就可以使用npm將代碼放到一個(gè)個(gè)包中，放到這里那里的node_modules中使用。很方便不是？感謝Node.js。

可在瀏覽器端，模塊化這事就沒那么簡(jiǎn)單了。

前端的模塊

前端的一個(gè)模塊包含很多東西，JavaScript、CSS、圖片字體等等。甚至，可能根據(jù)業(yè)務(wù)需要，還包含國(guó)際化的文件。一個(gè)模塊如果包含以上這些東西，復(fù)雜度就上了幾個(gè)數(shù)量級(jí)。

怎么復(fù)雜了？和高大上的iOS開發(fā)比起來，人家有SDK，代碼隨便往項(xiàng)目里扔，圖片扔，國(guó)際化有成熟的解決方案，最后構(gòu)建一下一個(gè)可運(yùn)行的應(yīng)用就出來了。

前端缺乏SDK，沒有成熟統(tǒng)一的開發(fā)方案，集成方案，前端模塊化之路很崎嶇。開發(fā)時(shí)，我們需要一種方式來組織，加載代碼，發(fā)布時(shí)，我們還需要另外一種方式將代碼、資源合并到一起發(fā)布。

眼前的現(xiàn)狀

TJ 給出了自己解決方案——Component。可以份文件開發(fā)，然后再把JavaScript、CSS和模板文件合并到一起。我只能說，理想很豐滿，現(xiàn)實(shí)很骨感，Component無法適應(yīng)各種奇葩的應(yīng)用場(chǎng)景。

或者我們自由一點(diǎn)——

依賴的第三方模塊，我們有Bower，好爽，運(yùn)行個(gè)命令，依賴就安裝好了。

但是Bower不是銀彈，Bower只解決了模塊依賴，安裝依賴的問題。Bower中的模塊沒有任何標(biāo)準(zhǔn)和規(guī)則，有的只有JavaScript，有的支持AMD，有的可能只有CSS。文件結(jié)構(gòu)，入口文件完全不一樣。并不是使用Bower安裝的模塊我們就可以使用同樣的方式使用任何一個(gè)模塊，使用某種工具將這些模塊打包發(fā)布！

AMD作為事實(shí)上的前端JavaScript模塊化標(biāo)準(zhǔn)，或可以出來解救我們。很多Bower模塊都是支持AMD規(guī)范的。而且AMD還提供了打包工具，總算有點(diǎn)解脫了。好景不長(zhǎng)……

每個(gè)模塊中的HTML怎么辦，如果我們使用的框架是Backbone，注定我們要將HTML模板轉(zhuǎn)換成JavaScript模塊，或者使用模塊加載器的插件來實(shí)現(xiàn)。如果我們使用AngularJS，那倒是可以交由AngularJS。發(fā)布時(shí)Backbone中的模塊使用AMD打包，AngularJS可以使用Grunt內(nèi)聯(lián)到頁(yè)面中。

HTML模塊也沒有固定的模式，沒有固定的SDK來解脫我們。我們只能組合現(xiàn)有的工具！

CSS就更不用說了，分開寫，使用LESS、SASS來組織？再一次沒有固定的模式?jīng)]有SDK。

還有圖片呢，字體呢？

拼湊的方案

前端如果想做模塊化開發(fā)，首先需要針對(duì)每一種資源（JavaScript、CSS、模板等）尋找一種模塊與集成方案，然后需要根據(jù)情況的不同選用不同的工具框架拼湊出來。

JavaScript

目前比較拿的出手的，也就是JavaScript的模塊化，比如AMD或者CMD等等，分別可以使用RequireJS和SeaJS。

去年在研究基于Backbone的框架Marionette時(shí)，想與Sea.js結(jié)合使用?，F(xiàn)在來看這種組合是完全沒有必要的。Marionette提供了模塊化的組織方案，反而生拉硬扯在一起，沖突得很難受。其實(shí)把JavaScript文件一列放在HTML中也沒什么問題。

究竟使用什么來實(shí)現(xiàn)JavaScript，往往與選擇的JavaScript框架有關(guān)，選Backbone可以AMD，也可以CMD。選AngularJS直接引用就行。

CSS

CSS模塊化應(yīng)該是兩方面的問題——

一是模塊必須有一套基礎(chǔ)樣式。與JavaScript相比，CSS沖突簡(jiǎn)直是家常便飯，Shadow DOM還沒成熟，原生的CSS樣式隔離還在路上。所以必須有一套基礎(chǔ)樣式來規(guī)定這一套模塊化組件的樣式。我們可以選Bootstrap，如果閑它太重，也可以自己寫。

其次，每個(gè)組件必須有命名空間，避免組件間樣式?jīng)_突。如果選擇使用LESS、SASS等，那就比較好辦，它們的縮進(jìn)語(yǔ)法避免寫很多重復(fù)的CSS代碼。

HTML模板

如果使用AngularJS，那AngularJS已經(jīng)幫您解決了模板模塊化的問題，AngularJS可以根據(jù)模塊代碼中的引用加載對(duì)應(yīng)的HTML。如果使用Backbone，可以選擇各種各樣的模板引擎，Mustache？不過比起AngularJS就低端些，我們必須自己處理模板文件，要么通過模塊加載器通過XHR請(qǐng)求，然后動(dòng)態(tài)編譯；或者將Mustache編譯成JS，在當(dāng)做模塊加載。

圖片、字體？

放在使用他們的模塊中，該怎么引用就怎么引用。

國(guó)際化文件？這些就不多說了，總之，每種文件需要選定一種開發(fā)的組織方式。

模塊分發(fā)

模塊采用統(tǒng)一的模式來開發(fā)之后，只需選定一種包的分發(fā)方式就行了——Bower。npm不適合這樣的場(chǎng)景，npm的版本管理太過細(xì)致了。如果同一個(gè)項(xiàng)目中允許出現(xiàn)同一模塊的不同版本，事情就做的太過復(fù)雜了。

發(fā)布上線

發(fā)布上線必須一個(gè)以終為始的過程。如果你不追求網(wǎng)站或者應(yīng)用的速度，那就把那些開發(fā)文件直接丟到生產(chǎn)服務(wù)器上去吧。別說，我還真見過這樣的商用的網(wǎng)站。

如果講究一些方案，資源合并成數(shù)個(gè)文件，代碼線上組合和運(yùn)行方式完全可以與本地開發(fā)不一樣。只需要功能在就行。

JavaScript代碼打成一個(gè)文件，或者兩個(gè)？都行。如果使用RequireJS，那RequireJS提供了打包的工具，打包成幾個(gè)文件，什么粒度，都行。如果是Sea.js也有對(duì)應(yīng)的工具。就算文件都是一個(gè)一個(gè)列出來，我們也總是可以打出來你想要的文件。

CSS等等其他資源都是如此，就算開發(fā)時(shí)各自不同的結(jié)構(gòu)模式，打包時(shí)都是可以打的。

至于上線CDN，版本號(hào)緩存什么的并不在本文的討論范圍之內(nèi)。

總結(jié)

前端模塊沒有什么特效藥。唯一要遵守的原則就是，比起Node.js來講，每種資源必須要有一種自己的開發(fā)和上線組織方式（Node.js開發(fā)和上線都是一致的），開發(fā)和上線完全可以是兩種方式，大可不必人云亦云，只要適合可以隨意組合；CSS在CSS Scoped Style正式使用之前，應(yīng)該有一套基礎(chǔ)樣式和沙盒（模塊樣式命名空間）。