伴隨著移動互聯(lián)的大潮,當(dāng)今越來越多的網(wǎng)站已經(jīng)從網(wǎng)頁模式進(jìn)化到了 Webapp 模式。它們運(yùn)行在現(xiàn)代的高級瀏覽器里,使用 HTML5、 CSS3、 ES6 等更新的技術(shù)來開發(fā)豐富的功能,網(wǎng)頁已經(jīng)不僅僅是完成瀏覽的基本需求,并且webapp通常是一個單頁面應(yīng)用,每一個視圖通過異步的方式加載,這導(dǎo)致頁面初始化和使用過程中會加載越來越多的 JavaScript 代碼,這給前端開發(fā)的流程和資源組織帶來了巨大的挑戰(zhàn)。
前端開發(fā)和其他開發(fā)工作的主要區(qū)別,首先是前端是基于多語言、多層次的編碼和組織工作,其次前端產(chǎn)品的交付是基于瀏覽器,這些資源是通過增量加載的方式運(yùn)行到瀏覽器端,如何在開發(fā)環(huán)境組織好這些碎片化的代碼和資源,并且保證他們在瀏覽器端快速、優(yōu)雅的加載和更新,就需要一個模塊化系統(tǒng),這個理想中的模塊化系統(tǒng)是前端工程師多年來一直探索的難題。
模塊系統(tǒng)主要解決模塊的定義、依賴和導(dǎo)出,先來看看已經(jīng)存在的模塊系統(tǒng)。
<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>
這是最原始的 JavaScript 文件加載方式,如果把每一個文件看做是一個模塊,那么他們的接口通常是暴露在全局作用域下,也就是定義在 window
對象中,不同模塊的接口調(diào)用都是一個作用域中,一些復(fù)雜的框架,會使用命名空間的概念來組織這些模塊的接口,典型的例子如 YUI 庫。
這種原始的加載方式暴露了一些顯而易見的弊端:
<script>
的書寫順序進(jìn)行加載服務(wù)器端的 Node.js 遵循 CommonJS規(guī)范,該規(guī)范的核心思想是允許模塊通過 require
方法來同步加載所要依賴的其他模塊,然后通過 exports
或 module.exports
來導(dǎo)出需要暴露的接口。
require("module");
require("../file.js");
exports.doStuff = function() {};
module.exports = someValue;
優(yōu)點(diǎn):
缺點(diǎn):
實(shí)現(xiàn):
Asynchronous Module Definition 規(guī)范其實(shí)只有一個主要接口 define(id?, dependencies?, factory)
,它要在聲明模塊的時候指定所有的依賴 dependencies
,并且還要當(dāng)做形參傳到 factory
中,對于依賴的模塊提前執(zhí)行,依賴前置。
define("module", ["dep1", "dep2"], function(d1, d2) {
return someExportedValue;
});
require(["module", "../file"], function(module, file) { /* ... */ });
優(yōu)點(diǎn):
缺點(diǎn):
實(shí)現(xiàn):
Common Module Definition 規(guī)范和 AMD 很相似,盡量保持簡單,并與 CommonJS 和 Node.js 的 Modules 規(guī)范保持了很大的兼容性。
define(function(require, exports, module) {
var $ = require('jquery');
var Spinning = require('./spinning');
exports.doSomething = ...
module.exports = ...
})
優(yōu)點(diǎn):
缺點(diǎn):
實(shí)現(xiàn):
Universal Module Definition 規(guī)范類似于兼容 CommonJS 和 AMD 的語法糖,是模塊定義的跨平臺解決方案。
EcmaScript6 標(biāo)準(zhǔn)增加了 JavaScript 語言層面的模塊體系定義。ES6 模塊的設(shè)計思想,是盡量的靜態(tài)化,使得編譯時就能確定模塊的依賴關(guān)系,以及輸入和輸出的變量。CommonJS 和 AMD 模塊,都只能在運(yùn)行時確定這些東西。
import "jquery";
export function doStuff() {}
module "localModule" {}
優(yōu)點(diǎn):
缺點(diǎn):
實(shí)現(xiàn):
可以兼容多種模塊風(fēng)格,盡量可以利用已有的代碼,不僅僅只是 JavaScript 模塊化,還有 CSS、圖片、字體等資源也需要模塊化。
前端模塊要在客戶端中執(zhí)行,所以他們需要增量加載到瀏覽器中。
模塊的加載和傳輸,我們首先能想到兩種極端的方式,一種是每個模塊文件都單獨(dú)請求,另一種是把所有模塊打包成一個文件然后只請求一次。顯而易見,每個模塊都發(fā)起單獨(dú)的請求造成了請求次數(shù)過多,導(dǎo)致應(yīng)用啟動速度慢;一次請求加載所有模塊導(dǎo)致流量浪費(fèi)、初始化過程慢。這兩種方式都不是好的解決方案,它們過于簡單粗暴。
分塊傳輸,按需進(jìn)行懶加載,在實(shí)際用到某些模塊的時候再增量更新,才是較為合理的模塊加載方案。
要實(shí)現(xiàn)模塊的按需加載,就需要一個對整個代碼庫中的模塊進(jìn)行靜態(tài)分析、編譯打包的過程。
在上面的分析過程中,我們提到的模塊僅僅是指JavaScript模塊文件。然而,在前端開發(fā)過程中還涉及到樣式、圖片、字體、HTML 模板等等眾多的資源。這些資源還會以各種方言的形式存在,比如 coffeescript、 less、 sass、眾多的模板庫、多語言系統(tǒng)(i18n)等等。
如果他們都可以視作模塊,并且都可以通過require
的方式來加載,將帶來優(yōu)雅的開發(fā)體驗,比如:
require("./style.css");
require("./style.less");
require("./template.jade");
require("./image.png");
那么如何做到讓 require
能加載各種資源呢?
在編譯的時候,要對整個代碼進(jìn)行靜態(tài)分析,分析出各個模塊的類型和它們依賴關(guān)系,然后將不同類型的模塊提交給適配的加載器來處理。比如一個用 LESS 寫的樣式模塊,可以先用 LESS 加載器將它轉(zhuǎn)成一個CSS 模塊,在通過 CSS 模塊把他插入到頁面的 <style>
標(biāo)簽中執(zhí)行。Webpack 就是在這樣的需求中應(yīng)運(yùn)而生。
同時,為了能利用已經(jīng)存在的各種框架、庫和已經(jīng)寫好的文件,我們還需要一個模塊加載的兼容策略,來避免重寫所有的模塊。
那么接下來,讓我們開始 Webpack 的神奇之旅吧。