前端工具之WebPack解密之背景

一、背景

如果你和我一樣，之前對于前端打包工具的發(fā)展一無所知，甚至于不知道這些工具出現(xiàn)的必要性。你可以瀏覽此部分的內(nèi)容，如果你不想知道這些或者對這些并不感興趣，可以直接跳過此部分。

互聯(lián)網(wǎng)程序現(xiàn)狀

隨著移動互聯(lián)的來襲，當前越來越多的網(wǎng)站已經(jīng)從單純的網(wǎng)頁模式，開始升級為webapp模式。它們運行在現(xiàn)代的瀏覽器中，使用HTML5、CSS3、ES6等技術(shù)開發(fā)，已經(jīng)從單一的瀏覽功能轉(zhuǎn)變?yōu)橐粋€基于瀏覽器的富客戶端。并且webapp通常是一個SPA(Single Page Application 單頁面應(yīng)用)。每個頁面（View）通過異步的方式加載，有著良好的用戶體驗。但是這樣做的結(jié)果是導致程序初始化和使用的過程中需要更多、更復雜的JavaScript代碼來實現(xiàn)，這就對前端程序的開發(fā)帶來巨大的挑戰(zhàn)！

模塊化系統(tǒng)的演變

隨著程序的復雜性的增加，項目結(jié)構(gòu)的龐大。把單一js文件按職責進行模塊化劃分。

我們在寫頁面的時候會這樣寫：

<script src="base.js"></script> <script src="utils.js"></script> <script src="vipPush.js"></script>

這是最基礎(chǔ)的JavaScript加載方式，每個JS的所有方法和屬性都是暴露在window對象中的（就像把所有代碼都放在一個命名空間或者同一個包下），借助全局對象，我們就能使用這些屬性和方法。如果更為復雜的程序會使用命名空間的概念來組織這些模塊的接口，比如：YUI

這種開發(fā)方式帶來的弊端：

• 全局的作用域下容易造成變量的相互沖突（這是一個很常見的問題）

• 文件只能按照<script>的書寫順序進行加載

• 開發(fā)者要解決各個模塊和代碼庫之間的依賴

• 如果按照此模式進行開發(fā)，長期下去整個項目（前端）代碼必定會混亂不堪

因為有了模塊的概念，讓我們的開發(fā)變得比較方便。讓我們可以很方便的使用別人的代碼，想要什么功能就加載什么模塊。這樣下去模塊的規(guī)范就變的更重要。目前：通用的JavaScript模塊主要有：

1. CommonJs

2. AMD、CMD

3. ES6的模塊

CommonJS： 同步加載解決方案

著名的node.js模塊系統(tǒng)就是參照CommonJS規(guī)范來實現(xiàn)的。其核心思想就是通過require來進行同步加載其它模塊，然后通過exports 或 module.exports來導出需要暴露的接口。

require("module"); require("./file.js"); exports.doStuff = function() {}; module.exports = someValue;

優(yōu)點：

1. 服務(wù)器端模塊便于重用

2. 在NPM里有很多功能模塊

3. 簡單易用

缺點：

1. 同步加載的方式注定不能用于客戶端（clients），同步的加載意味著阻塞加載，瀏覽器的加載方式是異步的

2. 不能非阻塞的并行加載多個模塊

代表：

1. 服務(wù)端 node.js

2. Browserify，瀏覽器端的 CommonJS 實現(xiàn)，可以使用 NPM 的模塊，但是編譯打包后的文件體積可能很大

AMD： 異步加載解決方案

AMD(asynchronous Module Definition)意思就是"異步模塊定義"，其規(guī)范主要是一個接口define(id?, dependencies?, factory),它采用的是異步加載的方式加載模塊，模塊的加載不影響它后面請語句的運行。所有執(zhí)行語句都是在模塊加載完成之后的回調(diào)函數(shù)中執(zhí)行的。

define("module", ["dep1", "dep2"], function(d1, d2) { return someExportedValue; }); require(["module", "../file"], function(module, file) { /* ... */ });

優(yōu)點：

1. 適合在瀏覽器環(huán)境中進行加載模塊

2. 可以并行多個模塊

缺點：

1. 提高了并發(fā)的成功，代碼的閱讀和書寫比較困難

2. 不符合通用模塊化的思維方式，是一種妥協(xié)的實現(xiàn)

實現(xiàn)：

• RequireJS

CMD： 另一種異步加載解決方案

CMD(Common Module Definition)規(guī)范與AMD很相似，盡量保持簡單，并與CommonJs和Node.js的Module規(guī)范保持了很大的兼容性

define(function(require, exports, module) { var $ = require('jquery'); var Spinning = require('./spinning'); exports.doSomething = ... module.exports = ... })

優(yōu)點：

1. 依賴就近，延遲執(zhí)行

2. 可以很容易在 Node.js 中運行

缺點：

1. 依賴 SPM 打包，模塊的加載邏輯偏重

實現(xiàn)：

• Sea.js

ES6 模塊

在ECMAScript2015(es6)中，增加了JavaScript語言層面上的模塊體系定義，其設(shè)計思想是：盡量的靜態(tài)化，使得編譯時就能確定模塊的依賴關(guān)系，以及輸入和輸出變量。

import "jquery"; export function doStuff() {} module "localModule" {}

優(yōu)點：

1. 容易進行靜態(tài)分析

2. 面向未來的 EcmaScript 標準

缺點：

1. 原生瀏覽器端還沒有實現(xiàn)該標準

2. 全新的命令字，新版的 Node.js才支持

實現(xiàn)：

• Babel

把程序所有的文件進行模塊化之后，我們還要處理一個問題那就是傳輸問題。模塊的化分讓我們可以讓程序變得可以組件化進行開發(fā)，組件雖然被客戶端執(zhí)行，但是依然要由服務(wù)器傳送給客戶端。

關(guān)于組件的傳送有兩個極端：

1. 每個組件，一個HTTP請求

• 優(yōu)點：僅僅傳送依賴項

• 缺點：請求多，負載高，更慢的啟動延遲

• 優(yōu)點： 更快，更低的延遲

• 傳送了沒有必要傳送的東西

讓我在這兩種情況之間做一個妥協(xié)：分塊傳輸，按需進行懶加載，在實際用某些模塊的時候進行增量的更新，才是比較合理的加載方案。

要實現(xiàn)這個功能，需要在編譯打包時進行靜態(tài)的分析、模塊進行分批次的打包。那么這個分批次誰來做呢？