[[188016]]

JavaScript 模塊化

當(dāng)年 Brendan Eich 草創(chuàng) JavaScript 之際，他應(yīng)該無(wú)法想象 JavaScript 在未來(lái)二十年內(nèi)發(fā)揮的巨大作用;同樣作為廣為詬病的過(guò)于隨意的語(yǔ)言，缺乏強(qiáng)有力的模塊化解決方案一直是 JavaScript 的缺陷之一。早期的 JavaScript 往往作為嵌入到 HTML 頁(yè)面中的用于控制動(dòng)畫(huà)與簡(jiǎn)單的用戶(hù)交互的腳本語(yǔ)言，我們習(xí)慣于將其直接嵌入到 script 標(biāo)簽中：

<!--html--> 
<script type="application/javascript"> 
    // module1 code 
    // module2 code 
</script> 

不過(guò)隨著單頁(yè)應(yīng)用與富客戶(hù)端的流行，不斷增長(zhǎng)的代碼庫(kù)也急需合理的代碼分割與依賴(lài)管理的解決方案，這也就是我們?cè)谲浖こ填I(lǐng)域所熟悉的模塊化(Modularity)。所謂模塊化主要是解決代碼分割、作用域隔離、模塊之間的依賴(lài)管理以及發(fā)布到生產(chǎn)環(huán)境時(shí)的自動(dòng)化打包與處理等多個(gè)方面。二十年間流行過(guò)的 JavaScript 模塊化解決方案包括但不限于直接聲明依賴(lài)(Directly Defined Dependences)、命名空間(Namespace Pattern)、模塊模式(Module Pattern)、依賴(lài)分離定義(Detached Dependency Definitions)、沙盒(Sandbox)、依賴(lài)注入(Dependency Injection)、CommonJS、AMD、UMD、標(biāo)簽化模塊(Labeled Modules)、YModules、ES 2015 Modules。

在早期的 Web 開(kāi)發(fā)中，所有的嵌入到網(wǎng)頁(yè)內(nèi)的 JavaScript 對(duì)象都會(huì)使用全局的 window 對(duì)象來(lái)存放未使用 var 定義的變量。大概在上世紀(jì)末，JavaScript 多用于解決簡(jiǎn)單的任務(wù)，這也就意味著我們只需編寫(xiě)少量的 JavaScript 代碼;不過(guò)隨著代碼庫(kù)的線性增長(zhǎng)，我們首先會(huì)碰到的就是所謂命名沖突(Name Collisions)困境：

// file greeting.js 
var helloInLang = { 
    en: 'Hello world!', 
    es: '¡Hola mundo!', 
    ru: 'Привет мир!' 
}; 
 
function writeHello(lang) { 
    document.write(helloInLang[lang]); 
} 
 
// file hello.js 
function writeHello() { 
    document.write('The script is broken'); 
} 

當(dāng)我們?cè)陧?yè)面內(nèi)同時(shí)引入這兩個(gè) JavaScript 腳本文件時(shí)，顯而易見(jiàn)兩個(gè)文件中定義的 writeHello 函數(shù)起了沖突，***調(diào)用的函數(shù)取決于我們引入的先后順序。此外在大型應(yīng)用中，我們不可能將所有的代碼寫(xiě)入到單個(gè) JavaScript 文件中;我們也不可能手動(dòng)地在 HTML 文件中引入全部的腳本文件，特別是此時(shí)還存在著模塊間依賴(lài)的問(wèn)題，相信很多開(kāi)發(fā)者都會(huì)遇到 jQuery 尚未定義這樣的問(wèn)題。不過(guò)物極必反，過(guò)度碎片化的模塊同樣會(huì)帶來(lái)性能的損耗與包體尺寸的增大，這包括了模塊加載、模塊解析、因?yàn)?Webpack 等打包工具包裹模塊時(shí)封裝的過(guò)多 IIFE 函數(shù)導(dǎo)致的 JavaScript 引擎優(yōu)化失敗等。譬如我們的源碼如下：

// index.js 
var total = 0 
total += require('./module_0') 
total += require('./module_1') 
total += require('./module_2') 
// etc. 
console.log(total) 
 
// module_0.js 
module.exports = 0 
 
// module_1.js 
module.exports = 1 

經(jīng)過(guò) Browserify 打包之后的代碼變成了如下式樣：

(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module '"+o+"'");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o<r.length;o++)s(r[o]);return s})({1:[function(require,module,exports){ 
module.exports = 0 
},{}],2:[function(require,module,exports){ 
module.exports = 1 
},{}],3:[function(require,module,exports){ 
module.exports = 10 
},{}],4:[function(require,module,exports){ 
module.exports = 100 
// etc. 

我們分別測(cè)試 100、1000 與 5000 模塊，可以發(fā)現(xiàn)隨著模塊數(shù)目的增長(zhǎng)***的包體大小并非線性增長(zhǎng)：

命名空間模式

命名空間模式始于 2002 年，顧名思義我們可以使用特殊的約定命名。譬如我們可以為某個(gè)模塊內(nèi)的變量統(tǒng)一添加 myApp_ 前綴，譬如 myApp_address，myApp_validateUser() 等等。同樣，我們也可以將函數(shù)賦值給模塊內(nèi)的變量或者對(duì)象的屬性，從而可以使得可以像 document.write() 這樣在子命名空間下定義函數(shù)而避免沖突。***采樣該設(shè)計(jì)模式的界面庫(kù)當(dāng)屬 Bindows，其是 Erik Arvidsson 創(chuàng)建于 2002 年。他沒(méi)有簡(jiǎn)單地為自定義函數(shù)或者對(duì)象添加命名前綴，而是將所有的 Bindows 當(dāng)中的數(shù)據(jù)與邏輯代碼封裝于某個(gè)全局對(duì)象內(nèi)，從而避免所謂的全局作用域污染。命名空間模式的設(shè)計(jì)思想如下所示：

// file app.js 
var app = {}; 
 
// file greeting.js 
app.helloInLang = { 
    en: 'Hello world!', 
    es: '¡Hola mundo!', 
    ru: 'Привет мир!' 
}; 
 
// file hello.js 
app.writeHello = function (lang) { 
    document.write(app.helloInLang[lang]); 
}; 

我們可以發(fā)現(xiàn)自定義代碼中的所有數(shù)據(jù)對(duì)象與函數(shù)都?xì)w屬于全局對(duì)象 app，不過(guò)顯而易見(jiàn)這種方式對(duì)于大型多人協(xié)同項(xiàng)目的可維護(hù)性還是較差，并且沒(méi)有解決模塊間依賴(lài)管理的問(wèn)題。另外有時(shí)候我們需要處理一些自動(dòng)執(zhí)行的 Pollyfill 性質(zhì)的代碼，就需要將模塊包裹在自調(diào)用的函數(shù)中，譬如在某個(gè)大型應(yīng)用中，我們的代碼可能會(huì)切分為如下幾個(gè)模塊：

// polyfill-vendor.js 
(function(){ 
    // polyfills-vendor code 
}()); 
 
// module1.js 
function module1(params){ 
    // module1 code 
    return module1; 
} 
 
// module3.js 
function module3(params){ 
    this.a = params.a; 
} 
 
module3.prototype.getA = function(){ 
    return this.a; 
}; 
 
// app.js 
var APP = {}; 
 
if(isModule1Needed){ 
    APP.module1 = module1({param1:1}); 
} 
 
APP.module3 = new module3({a: 42}); 

那么在引入的時(shí)候我們需要手動(dòng)地按照模塊間依賴(lài)順序引入進(jìn)來(lái)：

<!--html--> 
<script type="application/javascript" src="PATH/polyfill-vendor.js" ></script> 
<script type="application/javascript" src="PATH/module1.js" ></script> 
<script type="application/javascript" src="PATH/module2.js" ></script> 
<script type="application/javascript" src="PATH/app.js" ></script> 

不過(guò)這種方式對(duì)于模塊間通信也是個(gè)麻煩。命名空間模式算是如今 JavaScript 領(lǐng)域最為著名的模式之一，而在 Bindows 之后 Dojo(2005)，YUI(2005) 這些優(yōu)秀的界面框架也是承襲了這種思想。

依賴(lài)注入

Martin Fowler 于 2004 年提出了依賴(lài)注入(Dependency Injection)的概念，其主要用于 Java 中的組件內(nèi)通信;以 Spring 為代表的一系列支持依賴(lài)注入與控制反轉(zhuǎn)的框架將這種設(shè)計(jì)模式發(fā)揚(yáng)光大，并且成為了 Java 服務(wù)端開(kāi)發(fā)的標(biāo)準(zhǔn)模式之一。依賴(lài)注入的核心思想在于某個(gè)模塊不需要手動(dòng)地初始化某個(gè)依賴(lài)對(duì)象，而只需要聲明該依賴(lài)并由外部框架自動(dòng)實(shí)例化該對(duì)象實(shí)現(xiàn)并且傳遞到模塊內(nèi)。而五年之后的 2009 年 Misko Hevery 開(kāi)始設(shè)計(jì)新的 JavaScript 框架，并且使用了依賴(lài)注入作為其組件間通信的核心機(jī)制。這個(gè)框架就是***一時(shí)風(fēng)騷，甚至于說(shuō)是現(xiàn)代 Web 開(kāi)發(fā)先驅(qū)之一的 Angular。Angular 允許我們定義模塊，并且在顯式地聲明其依賴(lài)模塊而由框架完成自動(dòng)注入。其核心思想如下所示：

// file greeting.js 
angular.module('greeter', []) 
    .value('greeting', { 
        helloInLang: { 
            en: 'Hello world!', 
            es: '¡Hola mundo!', 
            ru: 'Привет мир!' 
        }, 
 
        sayHello: function(lang) { 
            return this.helloInLang[lang]; 
        } 
    }); 
 
// file app.js 
angular.module('app', ['greeter']) 
    .controller('GreetingController', ['$scope', 'greeting', function($scope, greeting) { 
        $scope.phrase = greeting.sayHello('en'); 
    }]); 

之后在 Angular 2 與 Slot 之中依賴(lài)注入仍是核心機(jī)制之一，這也是 Angular 一系的更多的被視為大而全的框架而不是小而美的庫(kù)的原因之一。

CommonJS

在 Node.js 橫空出世之前，就已經(jīng)有很多將運(yùn)行于客戶(hù)端瀏覽器中的 JavaScript 遷移運(yùn)行到服務(wù)端的框架;不過(guò)由于缺乏合適的規(guī)范，也沒(méi)有提供統(tǒng)一的與操作系統(tǒng)及運(yùn)行環(huán)境交互的接口，這些框架并未流行開(kāi)來(lái)。2009 年時(shí) Mozilla 的雇員 Kevin Dangoor 發(fā)表了博客討論服務(wù)端 JavaScript 代碼面臨的困境，號(hào)召所有有志于規(guī)范服務(wù)端 JavaScript 接口的志同道合的開(kāi)發(fā)者協(xié)同討論，群策群力，最終形成了 ServerJS 規(guī)范;一年之后 ServerJS 重命名為 CommonJS。后來(lái) CommonJS 內(nèi)的模塊規(guī)范成為了 Node.js 的標(biāo)準(zhǔn)實(shí)現(xiàn)規(guī)范，其基本語(yǔ)法為 var commonjs = require("./commonjs");，核心設(shè)計(jì)模式如下所示：

// file greeting.js 
var helloInLang = { 
    en: 'Hello world!', 
    es: '¡Hola mundo!', 
    ru: 'Привет мир!' 
}; 
 
var sayHello = function (lang) { 
    return helloInLang[lang]; 
} 
 
module.exports.sayHello = sayHello; 
 
// file hello.js 
var sayHello = require('./lib/greeting').sayHello; 
var phrase = sayHello('en'); 
console.log(phrase); 

該模塊實(shí)現(xiàn)方案主要包含 require 與 module 這兩個(gè)關(guān)鍵字，其允許某個(gè)模塊對(duì)外暴露部分接口并且由其他模塊導(dǎo)入使用。在 Node.js 中我們通過(guò)內(nèi)建輔助函數(shù)來(lái)使用 CommonJS 的導(dǎo)入導(dǎo)出功能，而在其他 JavaScript 引擎中我們可以將其包裹為如下形式：

(function (exports, require, module, __filename, __dirname) { 
    // ... 
    // Your code injects here! 
    // ... 
}); 

CommonJS 規(guī)范本身只是定義了不同環(huán)境下支持模塊交互性的最小化原則，其具備極大的可擴(kuò)展性。Node.js 中就對(duì) require 函數(shù)添加了 main 屬性，該屬性在執(zhí)行模塊所屬文件時(shí)指向 module 對(duì)象。Babel 在實(shí)現(xiàn) ES2015 Modules 的轉(zhuǎn)義時(shí)也擴(kuò)展了 require關(guān)鍵字：

export default something; 

Babel 將此類(lèi)型的導(dǎo)出轉(zhuǎn)化為了 CommonJS 模塊，簡(jiǎn)單而言形式如下：

export.default = something; 

Webpack 打包工具也使用了很多擴(kuò)展，譬如 require.ensure、require.cache、require.context 等等。CommonJS 算是目前***的模塊格式，我們不僅可以在 Node.js 中使用，還可以通過(guò)Browserify 與 Webpack 這樣的打包工具將代碼打包到客戶(hù)端運(yùn)行。另外我們需要注意的是，Node.js 中的模塊在加載之后是以單例化運(yùn)行，并且遵循值傳遞原則：

// obj.js 
module.exports = { 
    num:1 
} 
 
// primitive.js 
module.exports = 1; 
 
// modifier.js 
var number = require('./primitive'); 
var obj = require('./obj'); 
 
number = 2; 
obj.num = 2; 
 
console.log(number); 
console.log(obj); 
 
// main.js 
console.log(require('./primitive')); 
console.log(require('./obj')); 
 
require('./modifier.js') 
 
console.log(require('./primitive')); 
console.log(require('./obj')); 
 
// 執(zhí)行結(jié)果 
1 
{ num: 1 } 
2 
{ num: 2 } 
1 
{ num: 2 } 

AMD

就在 CommonJS 規(guī)范火熱討論的同時(shí)，很多開(kāi)發(fā)者也關(guān)注于如何實(shí)現(xiàn)模塊的異步加載。Web 應(yīng)用的性能優(yōu)化一直是前端工程實(shí)踐中不可避免的問(wèn)題，而模塊的異步加載以及預(yù)加載等機(jī)制能有效地優(yōu)化 Web 應(yīng)用的加載速度。Mozilla 的另一位雇員 James Burke 是討論組的活躍成員，他在 Dojo 1.7 版本中引入了異步模塊機(jī)制，并且在 2009 年開(kāi)發(fā)了 require.js 框架。James 的核心思想在于不應(yīng)該以同步方式加載模塊，而應(yīng)該充分利用瀏覽器的并發(fā)加載能力;James 按照其設(shè)計(jì)理念開(kāi)發(fā)出的模塊工具就是 AMD(Asynchronous Module Definition)，其基本形式如下：

define(["amd-module", "../file"], function(amdModule, file) { 
    require(["big-module/big/file"], function(big) { 
        var stuff = require("../my/stuff"); 
    }); 
}); 

而將我們上述使用的例子改寫(xiě)為 AMD 模式應(yīng)當(dāng)如下所示：

// file lib/greeting.js 
define(function() { 
    var helloInLang = { 
        en: 'Hello world!', 
        es: '¡Hola mundo!', 
        ru: 'Привет мир!' 
    }; 
 
    return { 
        sayHello: function (lang) { 
            return helloInLang[lang]; 
        } 
    }; 
}); 
 
// file hello.js 
define(['./lib/greeting'], function(greeting) { 
    var phrase = greeting.sayHello('en'); 
    document.write(phrase); 
}); 

hello.js 作為整個(gè)應(yīng)用的入口模塊，我們使用 define 關(guān)鍵字聲明了該模塊以及外部依賴(lài);當(dāng)我們執(zhí)行該模塊代碼時(shí)，也就是執(zhí)行 define 函數(shù)的第二個(gè)參數(shù)中定義的函數(shù)功能，其會(huì)在框架將所有的其他依賴(lài)模塊加載完畢后被執(zhí)行。這種延遲代碼執(zhí)行的技術(shù)也就保證了依賴(lài)的并發(fā)加載。從我個(gè)人而言，AMD 及其相關(guān)技術(shù)對(duì)于前端開(kāi)發(fā)的工程化進(jìn)步有著非常積極的意義，不過(guò)隨著以 npm 為主導(dǎo)的依賴(lài)管理機(jī)制的統(tǒng)一，越來(lái)越多的開(kāi)發(fā)者放棄了使用 AMD 模式。

UMD

AMD 與 CommonJS 雖然師出同源，但還是分道揚(yáng)鑣，關(guān)注于代碼異步加載與最小化入口模塊的開(kāi)發(fā)者將目光投注于 AMD;而隨著 Node.js 以及 Browserify 的流行，越來(lái)越多的開(kāi)發(fā)者也接受了 CommonJS 規(guī)范。令人扼腕嘆息的是，符合 AMD 規(guī)范的模塊并不能直接運(yùn)行于實(shí)踐了 CommonJS 模塊規(guī)范的環(huán)境中，符合 CommonJS 規(guī)范的模塊也不能由 AMD 進(jìn)行異步加載，整個(gè) JavaScript 生態(tài)圈貌似分崩離析。2011 年中，UMD，也就是 Universal Module Definition 規(guī)范正是為了彌合這種不一致性應(yīng)運(yùn)而出，其允許在環(huán)境中同時(shí)使用 AMD 與 CommonJS 規(guī)范。Q 算是 UMD 的***規(guī)范實(shí)現(xiàn)，其能同時(shí)運(yùn)行于瀏覽器環(huán)境(以腳本標(biāo)簽形式嵌入)與服務(wù)端的 Node.js 或者 Narwhal(CommonJS 模塊)環(huán)境中;稍后，James 也為 Q 添加了對(duì)于 AMD 的支持。我們將上述例子中的 greeting.js 改寫(xiě)為同時(shí)支持 CommonJS 與 AMD 規(guī)范的模塊：

(function(define) { 
    define(function () { 
        var helloInLang = { 
            en: 'Hello world!', 
            es: '¡Hola mundo!', 
            ru: 'Привет мир!' 
        }; 
 
        return { 
            sayHello: function (lang) { 
                return helloInLang[lang]; 
            } 
        }; 
    }); 
}( 
    typeof module === 'object' && module.exports && typeof define !== 'function' ? 
    function (factory) { module.exports = factory(); } : 
    define 
)); 

該模式的核心思想在于所謂的 IIFE(Immediately Invoked Function Expression)，該函數(shù)會(huì)根據(jù)環(huán)境來(lái)判斷需要的參數(shù)類(lèi)別，譬如在 CommonJS 環(huán)境下上述代碼會(huì)以如下方式執(zhí)行：

function (factory) { 
    module.exports = factory(); 
}  

而如果是在 AMD 模塊規(guī)范下，函數(shù)的參數(shù)就變成了 define。正是因?yàn)檫@種運(yùn)行時(shí)的靈活性是我們能夠?qū)⑼环荽a運(yùn)行于不同的環(huán)境中。

ES2015 Modules

JavaScript 模塊規(guī)范領(lǐng)域群雄逐鹿，各領(lǐng)風(fēng)騷，作為 ECMAScript 標(biāo)準(zhǔn)的起草者 TC39 委員會(huì)自然也不能置身事外。ES2015 Modules 規(guī)范始于 2010 年，主要由 Dave Herman 主導(dǎo);隨后的五年中 David 還參與了 asm.js，emscription，servo，等多個(gè)重大的開(kāi)源項(xiàng)目，也使得 ES2015 Modules 的設(shè)計(jì)能夠從多方面進(jìn)行考慮與權(quán)衡。而***的模塊化規(guī)范定義于 2015 年正式發(fā)布，也就是被命名為 ES2015 Modules。我們上述的例子改寫(xiě)為 ES2015 Modules 規(guī)范如下所示：

// file lib/greeting.js 
const helloInLang = { 
    en: 'Hello world!', 
    es: '¡Hola mundo!', 
    ru: 'Привет мир!' 
}; 
 
export const greeting = { 
    sayHello: function (lang) { 
        return helloInLang[lang]; 
    } 
}; 
 
// file hello.js 
import { greeting } from "./lib/greeting"; 
const phrase = greeting.sayHello("en"); 
document.write(phrase); 

ES2015 Modules 中主要的關(guān)鍵字就是 import 與 export，前者負(fù)責(zé)導(dǎo)入模塊而后者負(fù)責(zé)導(dǎo)出模塊。完整的導(dǎo)出語(yǔ)法如下所示：

// default exports 
export default 42; 
export default {}; 
export default []; 
export default foo; 
export default function () {} 
export default class {} 
export default function foo () {} 
export default class foo {} 
 
// variables exports 
export var foo = 1; 
export var foo = function () {}; 
export var bar; // lazy initialization 
export let foo = 2; 
export let bar; // lazy initialization 
export const foo = 3; 
export function foo () {} 
export class foo {} 
 
// named exports 
export {foo}; 
export {foo, bar}; 
export {foo as bar}; 
export {foo as default}; 
export {foo as default, bar}; 
 
// exports from 
export * from "foo"; 
export {foo} from "foo"; 
export {foo, bar} from "foo"; 
export {foo as bar} from "foo"; 
export {foo as default} from "foo"; 
export {foo as default, bar} from "foo"; 
export {default} from "foo"; 
export {default as foo} from "foo"; 

相對(duì)應(yīng)的完整的支持的導(dǎo)入方式如下所示：

// default imports 
import foo from "foo"; 
import {default as foo} from "foo"; 
 
// named imports 
import {bar} from "foo"; 
import {bar, baz} from "foo"; 
import {bar as baz} from "foo"; 
import {bar as baz, xyz} from "foo"; 
 
// glob imports 
import * as foo from "foo"; 
 
// mixing imports 
import foo, {baz as xyz} from "foo"; 
import * as bar, {baz as xyz} from "foo"; 
import foo, * as bar, {baz as xyz} from "foo"; 

ES2015 Modules 作為 JavaScript 官方標(biāo)準(zhǔn)，日漸成為了開(kāi)發(fā)者的主流選擇。雖然我們目前還不能直接保證在所有環(huán)境(特別是舊版本瀏覽器)中使用該規(guī)范，但是通過(guò) Babel 等轉(zhuǎn)化工具能幫我們自動(dòng)處理向下兼容。此外 ES2015 Modules 還是有些許被詬病的地方，譬如導(dǎo)入語(yǔ)句只能作為模塊頂層的語(yǔ)句出現(xiàn)，不能出現(xiàn)在 function 里面或是 if 里面：

if(Math.random()>0.5){ 
  import './module1.js'; // SyntaxError: Unexpected keyword 'import' 
} 
const import2 = (import './main2.js'); // SyntaxError 
try{ 
  import './module3.js'; // SyntaxError: Unexpected keyword 'import' 
}catch(err){ 
  console.error(err); 
} 
const moduleNumber = 4; 
 
import module4 from `module${moduleNumber}`; // SyntaxError: Unexpected token 

并且 import 語(yǔ)句會(huì)被提升到文件頂部執(zhí)行，也就是說(shuō)在模塊初始化的時(shí)候所有的 import 都必須已經(jīng)導(dǎo)入完成：

import './module1.js'; 
 
alert('code1'); 
 
import module2 from './module2.js'; 
 
alert('code2'); 
 
import module3 from './module3.js'; 
 
// 執(zhí)行結(jié)果 
module1 
module2 
module3 
code1 
code2 

并且 import 的模塊名只能是字符串常量，導(dǎo)入的值也是不可變對(duì)象;比如說(shuō)你不能 import { a } from './a' 然后給 a 賦值個(gè)其他什么東西。這些設(shè)計(jì)雖然使得靈活性不如 CommonJS 的 require，但卻保證了 ES6 Modules 的依賴(lài)關(guān)系是確定(Deterministic)的，和運(yùn)行時(shí)的狀態(tài)無(wú)關(guān)，從而也就保證了 ES6 Modules 是可以進(jìn)行可靠的靜態(tài)分析的。對(duì)于主要在服務(wù)端運(yùn)行的 Node 來(lái)說(shuō)，所有的代碼都在本地，按需動(dòng)態(tài) require 即可，但對(duì)于要下發(fā)到客戶(hù)端的 Web 代碼而言，要做到高效的按需使用，不能等到代碼執(zhí)行了才知道模塊的依賴(lài)，必須要從模塊的靜態(tài)分析入手。這是 ES6 Modules 在設(shè)計(jì)時(shí)的一個(gè)重要考量，也是為什么沒(méi)有直接采用 CommonJS。此外我們還需要關(guān)注下的是 ES2015 Modules 在瀏覽器內(nèi)的原生支持情況，盡管我們可以通過(guò) Webpack 等打包工具將應(yīng)用打包為單個(gè)包文件。目前主流瀏覽器中默認(rèn)支持 ES2015 Modules 只有 Safari，而 Firefox 在 54 版本之后允許用戶(hù)手動(dòng)啟用該特性。以 Firefox 為例，如果我們?cè)跒g覽器中使用 ES2015 Modules，我們需要聲明入口模塊：

<script type="module" scr="PATH/file.js"></script> 

這里的 module 關(guān)鍵字就告訴瀏覽器該腳本中包含了對(duì)于其他腳本的導(dǎo)入語(yǔ)句，需要進(jìn)行預(yù)先處理;不過(guò)問(wèn)題來(lái)了，那么 JavaScript 解釋器又該如何判斷某個(gè)文件是否為模塊。社區(qū)也經(jīng)過(guò)很多輪的討論，我們可以來(lái)看下簡(jiǎn)單的例子：

<!--index.html--> 
<!DOCTYPE html> 
<html> 
  <head> 
    <script type="module" src="main.js"></script> 
  </head> 
  <body> 
  </body> 
</html> 

main.js 的代碼實(shí)現(xiàn)如下：

// main.js 
import utils from "./utils.js"; 
 
utils.alert(` 
  JavaScript modules work in this browser: 
  https://blog.whatwg.org/js-modules 
`); 

待導(dǎo)入的模塊如下：

// utils.js 
export default { 
    alert: (msg)=>{ 
        alert(msg); 
    } 
}; 

我們可以發(fā)現(xiàn)，在 import 語(yǔ)句中我們提供了 .js 擴(kuò)展名，這也是區(qū)別于打包工具的重要特性之一，往往打包工具中并不需要我們提供擴(kuò)展名。此外，在瀏覽器中進(jìn)行模塊的動(dòng)態(tài)加載，也要求待加載文件具有正確的 MIME 類(lèi)型。我們常用的正確的模塊地址譬如：

https://example.com/apples.js 
http:example.com\pears.mjs (becomes http://example.com/pears.mjs as step 1 parses with no base URL) 
//example.com/bananas 
./strawberries.js.cgi 
../lychees 
/limes.jsx 
data:text/javascript,export default ‘grapes’; 
blob:https://whatwg.org/d0360e2f-caee-469f-9a2f-87d5b0456f6f 

不過(guò)筆者覺(jué)得有個(gè)不錯(cuò)的特性在于瀏覽器中支持 CORS 協(xié)議，跨域加載其他域中的腳本。在瀏覽器中加載進(jìn)來(lái)的模塊與直接加載的腳本的作用域也是不一致的，并且不需要 use strict 聲明其也默認(rèn)處于嚴(yán)格模式下：

var x = 1; 
 
alert(x === window.x);//false 
alert(this === undefined);// true 

瀏覽器對(duì)于模塊的加載默認(rèn)是異步延遲進(jìn)行的，即模塊腳本的加載并不會(huì)阻塞瀏覽器的解析行為，而是并發(fā)加載并在頁(yè)面加載完畢后進(jìn)行解析，也就是所有的模塊腳本具有 defer 屬性。我們也可以為腳本添加 async 屬性，即指明該腳本會(huì)在加載完畢后立刻執(zhí)行。這一點(diǎn)與傳統(tǒng)的非模塊腳本相比很大不同，傳統(tǒng)的腳本會(huì)阻塞瀏覽器解析直到抓取完畢，在抓取之后也會(huì)立刻進(jìn)行執(zhí)行操作。整個(gè)加載流程如下所示：

【本文是51CTO專(zhuān)欄作者“張梓雄 ”的原創(chuàng)文章，如需轉(zhuǎn)載請(qǐng)通過(guò)51CTO與作者聯(lián)系】

戳這里，看該作者更多好文