資訊專欄INFORMATION COLUMN
摘要：并不是使用安裝的模塊我們就可以使用同樣的方式使用任何一個模塊，使用某種工具將這些模塊打包發布作為事實上的前端模塊化標準，或可以出來解救我們。目前比較拿的出手的，也就是的模塊化，比如或者等等，分別可以使用和。
Teambition是一家追求卓越技術的公司，我們工程師都很Geek，我們使用了很多新潮的，開源的技術。同時我們也貢獻了很多開源的項目。我們希望能夠把一些技術經驗分享給大家。于是有了這個「創作隨筆」。廢話休說，「創作隨筆」第一彈，來自我們的前端工程師寸志，談一談他在前端模塊化開發方面的一些感想。
在模塊化方面，Node.js就顯得游刃有余。
作為用戶，我們把代碼放到一個個JavaScript文件中，然后Node.js就有一套規則幫我們把這些代碼組織起來，Node.js還有包的概念，于是我們就可以使用npm將代碼放到一個個包中，放到這里那里的node_modules中使用。很方便不是？感謝Node.js。
可在瀏覽器端，模塊化這事就沒那么簡單了。
前端的模塊前端的一個模塊包含很多東西，JavaScript、CSS、圖片字體等等。甚至，可能根據業務需要，還包含國際化的文件。一個模塊如果包含以上這些東西，復雜度就上了幾個數量級。
怎么復雜了？和高大上的iOS開發比起來，人家有SDK，代碼隨便往項目里扔，圖片扔，國際化有成熟的解決方案，最后構建一下一個可運行的應用就出來了。
前端缺乏SDK，沒有成熟統一的開發方案，集成方案，前端模塊化之路很崎嶇。開發時，我們需要一種方式來組織，加載代碼，發布時，我們還需要另外一種方式將代碼、資源合并到一起發布。
眼前的現狀TJ 給出了自己解決方案——Component。可以份文件開發，然后再把JavaScript、CSS和模板文件合并到一起。我只能說，理想很豐滿，現實很骨感，Component無法適應各種奇葩的應用場景。
或者我們自由一點——
依賴的第三方模塊，我們有Bower，好爽，運行個命令，依賴就安裝好了。
但是Bower不是銀彈，Bower只解決了模塊依賴，安裝依賴的問題。Bower中的模塊沒有任何標準和規則，有的只有JavaScript，有的支持AMD，有的可能只有CSS。文件結構，入口文件完全不一樣。并不是使用Bower安裝的模塊我們就可以使用同樣的方式使用任何一個模塊，使用某種工具將這些模塊打包發布！
AMD作為事實上的前端JavaScript模塊化標準，或可以出來解救我們。很多Bower模塊都是支持AMD規范的。而且AMD還提供了打包工具，總算有點解脫了。好景不長……
每個模塊中的HTML怎么辦，如果我們使用的框架是Backbone，注定我們要將HTML模板轉換成JavaScript模塊，或者使用模塊加載器的插件來實現。如果我們使用AngularJS，那倒是可以交由AngularJS。發布時Backbone中的模塊使用AMD打包，AngularJS可以使用Grunt內聯到頁面中。
HTML模塊也沒有固定的模式，沒有固定的SDK來解脫我們。我們只能組合現有的工具！
CSS就更不用說了，分開寫，使用LESS、SASS來組織？再一次沒有固定的模式沒有SDK。
還有圖片呢，字體呢？
拼湊的方案前端如果想做模塊化開發，首先需要針對每一種資源（JavaScript、CSS、模板等）尋找一種模塊與集成方案，然后需要根據情況的不同選用不同的工具框架拼湊出來。
JavaScript目前比較拿的出手的，也就是JavaScript的模塊化，比如AMD或者CMD等等，分別可以使用RequireJS和SeaJS。
去年在研究基于Backbone的框架Marionette時，想與Sea.js結合使用。現在來看這種組合是完全沒有必要的。Marionette提供了模塊化的組織方案，反而生拉硬扯在一起，沖突得很難受。其實把JavaScript文件一列放在HTML中也沒什么問題。
究竟使用什么來實現JavaScript，往往與選擇的JavaScript框架有關，選Backbone可以AMD，也可以CMD。選AngularJS直接引用就行。
CSSCSS模塊化應該是兩方面的問題——
一是模塊必須有一套基礎樣式。與JavaScript相比，CSS沖突簡直是家常便飯，Shadow DOM還沒成熟，原生的CSS樣式隔離還在路上。所以必須有一套基礎樣式來規定這一套模塊化組件的樣式。我們可以選Bootstrap，如果閑它太重，也可以自己寫。
其次，每個組件必須有命名空間，避免組件間樣式沖突。如果選擇使用LESS、SASS等，那就比較好辦，它們的縮進語法避免寫很多重復的CSS代碼。
HTML模板如果使用AngularJS，那AngularJS已經幫您解決了模板模塊化的問題，AngularJS可以根據模塊代碼中的引用加載對應的HTML。如果使用Backbone，可以選擇各種各樣的模板引擎，Mustache？不過比起AngularJS就低端些，我們必須自己處理模板文件，要么通過模塊加載器通過XHR請求，然后動態編譯；或者將Mustache編譯成JS，在當做模塊加載。
圖片、字體？放在使用他們的模塊中，該怎么引用就怎么引用。
國際化文件？這些就不多說了，總之，每種文件需要選定一種開發的組織方式。
模塊分發模塊采用統一的模式來開發之后，只需選定一種包的分發方式就行了——Bower。npm不適合這樣的場景，npm的版本管理太過細致了。如果同一個項目中允許出現同一模塊的不同版本，事情就做的太過復雜了。
發布上線發布上線必須一個以終為始的過程。如果你不追求網站或者應用的速度，那就把那些開發文件直接丟到生產服務器上去吧。別說，我還真見過這樣的商用的網站。
如果講究一些方案，資源合并成數個文件，代碼線上組合和運行方式完全可以與本地開發不一樣。只需要功能在就行。
JavaScript代碼打成一個文件，或者兩個？都行。如果使用RequireJS，那RequireJS提供了打包的工具，打包成幾個文件，什么粒度，都行。如果是Sea.js也有對應的工具。就算文件都是一個一個列出來，我們也總是可以打出來你想要的文件。
CSS等等其他資源都是如此，就算開發時各自不同的結構模式，打包時都是可以打的。
至于上線CDN，版本號緩存什么的并不在本文的討論范圍之內。
總結前端模塊沒有什么特效藥。唯一要遵守的原則就是，比起Node.js來講，每種資源必須要有一種自己的開發和上線組織方式（Node.js開發和上線都是一致的），開發和上線完全可以是兩種方式，大可不必人云亦云，只要適合可以隨意組合；CSS在CSS Scoped Style正式使用之前，應該有一套基礎樣式和沙盒（模塊樣式命名空間）。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/78153.html
摘要：前端雜談第一個問題什么是什么是是我們在代碼中經常看到的鍵值對例如上面代碼中的節點有三個是對應的節點的對象屬性例如第二個問題從上面的例子來看似乎和是相同的那么他們有什么區別呢讓我們來看另一段代碼在頁面加載后我們在這個中輸入注意這段代碼 前端雜談: Attribute VS Property 第一個問題: 什么是 attribute & 什么是 property ? attribute 是...
摘要：而在這個微服務下，同樣需要進行數據操作，我不可能還要在下再一次進行集成，這樣大大的增加了代碼量。其次，是將有關數據操作的都單獨部署成一個模塊，比如我集成的模塊，集成的模塊，使用作為內存緩存模塊。 前言 相對于 spring 對 mybatis 以及 redis 等的整合所需要的各種配置文件，在 springboot 下，已經大大的簡化了，你可能只是需要增加個依賴，加個注解，然后在配置文...
閱讀 2060·2023-04-25 21:11
閱讀 2963·2021-09-30 09:47
閱讀 2271·2021-09-24 09:48
閱讀 4427·2021-08-23 09:43
閱讀 895·2019-08-30 15:54
閱讀 559·2019-08-28 18:01
閱讀 1397·2019-08-27 10:55
閱讀 588·2019-08-27 10:55
