在JavaScript發(fā)展的初期是為了實現(xiàn)簡單的頁面交互邏輯, 就這么一句話.

如今, 瀏覽器性能得到極大的提高, 很多頁面邏輯遷移到了客戶端(表單驗證等), 隨著Web 2.0時代的到來, ajax技術(shù)得到廣泛使用, jQuery, angularjs, vuejs等前端庫也層出不窮, 前端代碼越來越龐大.

這時JavaScript作為嵌入式的腳本語言的定位動搖了, JavaScript卻沒有為組織代碼提供任何明顯的幫助, 甚至沒有類的概念(當(dāng)然, 你也可以利用原型鏈來模擬面向?qū)ο蚓幊?, 更不用說模塊了, JavaScript極其簡單的代碼組織規(guī)范不足以駕馭如此龐大規(guī)模的代碼.

• 前端模塊化的價值
  ==========

引用下Sea.js中關(guān)于前端模塊化的價值一文.詳細(xì)請點擊此處

• 前端模塊化規(guī)范標(biāo)準(zhǔn)
  ============
  目前的主要有三種:
  1. CommonJS(Node.js)
  2. AMD(Require.js)
  3. CMD(Sea.js)

• CommonJS

CommonJS是服務(wù)器模塊的規(guī)范, Node.js采用了這個規(guī)范. 根據(jù)CommonJS規(guī)范, 一個單獨的文件就是一個模塊, 每一個模塊都是一個單獨的作用域, 在一個文件定義的變量(還包括函數(shù)和類), 都是私有的, 對其他文件是不可見的. CommonJS規(guī)范加載模塊是同步的, 也就是說, 只有加載完成后, 才能執(zhí)行后面的操作.

var x = 5;                    
var add = function(a, b){
    return a + b;
};
module.exports.x = x;            //對外提供的接口變量
module.exports.addX = add;        // 對外提供的接口函數(shù)

• AMD

由于Node.js主要用于服務(wù)器編程, 模塊文件一般都已經(jīng)存在于本地硬盤, 所以加載起來比較快, 不用考慮非同步加載的方式, 因此CommonJS規(guī)范比較適用. 但是, 如果是瀏覽器環(huán)境, 要從服務(wù)器端加載模塊, 這時就必須采用非同步模式, 因此瀏覽器端一般采用AMD規(guī)范. 如下規(guī)范定義及一般寫法.

// 規(guī)范
define(id?, dependencies?, factory);
define.amd = {};

// 寫法1
define(function(require, exports, module){
    var $ = require('jquery');
    // 代碼塊
});

// 寫法2
define(['jquery'], function($){
    var btn = $('#btn1');
    // 代碼塊
});

// 寫法3
define(['require', 'jquery'], function(require){
    var $ = require('jquery');
    // 代碼塊
});

• CMD

CMD規(guī)范和AMD類似, 都主要運行于瀏覽器端, 寫法上看起來也很類似. 主要區(qū)別在于模塊初始化時機(jī), AMD中只要模塊作為依賴時, 就會加載并初始化, 而CMD中, 模塊作為依賴且被引用時才會初始化, 否則只會加載.
規(guī)范定義及一般寫法如下:

// 規(guī)范
define(factory);
defind.cmd = {};

// 寫法1
define(function(require, exports, modules){
    var $ = require('jquery');
    // 代碼塊
});

// 寫法2
define(['jquery'], function(require, exports, module){
    var $ = require('jquery');
    // 代碼塊
});

• 兼容AMD, CMD及非模塊化

很多時候, 如果我們引用第三方組件時, 并沒有采用模塊化開發(fā), 通常我們自己需要包裝一下或通過模塊加載器的shim插件支持模塊化引用依賴. 現(xiàn)在很多第三方庫已經(jīng)默認(rèn)支持AMD規(guī)范的引用, 根據(jù)以上模塊定義規(guī)范, 開放給第三方使用的組件能兼容不同的規(guī)范, 如下示例:

(function(root, factory){
    if (typeof define === 'function' && (define.amd || define.cmd)){
        define(function(require, exports, module){
            return factory(root);
        });
    }else{
        root.dialog = factory(root);
    }
})(window, function(root){
    // code here
   return dialog;
});

• AMD與CMD

對于一般使用者來說, require.js, sea.js都是不錯的選擇, 對外調(diào)用API上, CMD的API設(shè)計更簡單, 職能更單一, 整體實現(xiàn)更輕量, 也更傾向于CommonJS的規(guī)范寫法, 提供依賴就近聲明. 前后端共享模塊時, 只需要去掉define的包裝頭部就行了. 雖然AMD也支持CommonJS規(guī)范寫法, 但不是強(qiáng)制的.

同時, 對于依賴的加載順序, AMD是不保證按照書寫的順序按序初始化模塊的, 而這點CMD也更接近CommonJS規(guī)范, 對于使用者來說require就是同步的.

• 模塊化開發(fā)上線部署

  1. 壓縮
  2. 合并
  3. 更新版本

不能直接壓縮:
因為模塊加載器在分析模塊的依賴時, 會先將模塊的工廠函數(shù)factory.toString(),
然后通過正則匹配require局部變量, 這樣意味著不能直接通過壓縮工具進(jìn)行壓縮,
若require這個變量被替換, 加載器與自動化工具將無法獲取模塊的依賴.

不能直接合并
我們在開發(fā)時, 通常是省略模塊的ID的, 如果多個模塊直接合并成一個文件, 這樣加載器無法區(qū)分不同的模塊.

所以采用模塊化開發(fā)部署時, 壓縮前通常通過工具先提取依賴, 這樣require應(yīng)該可以當(dāng)做普通變量直接壓縮了, 同時也不再需要加載器分析提取依賴, 對于提升性能也是蠻有好處的. 合并前同樣也需要借助工具先提取各個模塊的ID, 然后才能按照合并配置進(jìn)行合并.整個過程如下:

image.png

Sea.js和Require.js官方都提供了構(gòu)建工具, 如Seajs的spm, Requirejs的r.js, 當(dāng)然也有很多grunt和glup插件可使用, 區(qū)別于普通壓縮合并就是要有提取依賴及模塊ID的能力.

對比構(gòu)建工具使用感受, spm的整個上手并不是那么順暢, 配置太復(fù)雜. r.js使用相對簡單, 只需要配置好合并的配置文件即可, 其它grunt或glup提供的插件相對靈活, 可根據(jù)自身業(yè)務(wù)靈活配置.

完成壓縮合并后, 最后一步就是更新版本號上線了, 通常是需要手動更新版本號, 或是修改控制版本號的配置參數(shù). 這一步基本上還是需要人力手動干預(yù)一下. 當(dāng)然如果合并是通過后端的combo服務(wù)就不需要了. 不管怎么說, 通過這些工具的組合使用, 整個開發(fā)上線流程基本實現(xiàn)自動化了, 比較方便.

• FIS的集成解決方案

用過FIS的小伙伴們都知道, 采用FIS開發(fā), 整體過程相當(dāng)順暢, 對于前端開發(fā), 性能, 部署各方面的問題基本都考慮到了, 內(nèi)置的小巧mod.js加載器, 就是一個特別輕量的模塊加載器, 不需要做依賴分析, FIS強(qiáng)大的編譯能力已經(jīng)提前提取了依賴關(guān)系并生成jsmap.json, 已經(jīng)前置依賴了, 一個輕量的加載器就足夠了, 編譯的同時自動修改新生成的版本號, 整個過程在FIS下輕松自動完成.
1. 語言擴(kuò)展能力(less, coffee, jade)
2. 前端模板預(yù)編譯
3. xss自動轉(zhuǎn)義, 無需手動干預(yù)
4. 多域名支持, 動態(tài)切換
5. 編譯后自動修改版本號(包括圖片的引用)
6. 線上本地調(diào)試功能...

本文部份內(nèi)容引用至: 前端模塊化開發(fā)方案小對比