前端開發(fā)和其他開發(fā)工作的主要區(qū)別，首先是前端是基于多語言、多層次的編碼和組織工作，其次前端產(chǎn)品的交付是基于瀏覽器，這些資源是通過增量加載的方式運(yùn)行到瀏覽器端，
如何在開發(fā)環(huán)境組織好這些碎片化的代碼和資源，并且保證他們?cè)跒g覽器端快速、優(yōu)雅的加載和更新，就需要一個(gè)模塊化系統(tǒng)，這個(gè)理想中的模塊化系統(tǒng)是前端工程師多年來一直探索的難題。

模塊系統(tǒng)的演進(jìn)

script 標(biāo)簽

<script src="module1.js"></script> <script src="module2.js"></script> <script src="module3.js"></script>?

這是最原始的 JavaScript 文件加載方式，這種原始的加載方式暴露了一些顯而易見的弊端：

• 文件只能按照<script>?的書寫順序進(jìn)行加載
• 在大型項(xiàng)目中各種資源難以管理，長期積累的問題導(dǎo)致代碼庫混亂不堪
• 全局作用域下容易造成變量沖突

?

CommonJS

該規(guī)范的核心思想是允許模塊通過 require 方法來同步加載所要依賴的其他模塊，然后通過 exports 或 module.exports 來導(dǎo)出需要暴露的接口

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

優(yōu)點(diǎn)：

• 服務(wù)器端模塊便于重用
• NPM 中已經(jīng)有將近20萬個(gè)可以使用模塊包
• 簡(jiǎn)單并容易使用

缺點(diǎn)：

• 同步的模塊加載方式不適合在瀏覽器環(huán)境中，同步意味著阻塞加載，瀏覽器資源是異步加載的
• 不能非阻塞的并行加載多個(gè)模塊

實(shí)現(xiàn)：

• 服務(wù)器端的?Node.js

?

AMD

CommonJS是主要為了JS在后端的表現(xiàn)制定的，他是不適合前端的，于是乎，AMD(異步模塊定義)出現(xiàn)了，它就主要為前端JS的表現(xiàn)制定規(guī)范。

AMD（Asynchronous Module Definition）就只有一個(gè)接口：define(id?,dependencies?,factory);

它要在聲明模塊的時(shí)候制定所有的依賴(dep)，并且還要當(dāng)做形參傳到factory中，對(duì)于依賴的模塊提前執(zhí)行，依賴前置，像這樣：

define(['dep1','dep2'],function(dep1,dep2){...});

要是沒什么依賴，就定義簡(jiǎn)單的模塊，下面這樣就可以啦：

define(function(){var exports = {};exports.method = function(){...};return exports;});

優(yōu)點(diǎn)：

• 適合在瀏覽器環(huán)境中異步加載模塊
• 可以并行加載多個(gè)模塊

缺點(diǎn)：

• 提高了開發(fā)成本，代碼的閱讀和書寫比較困難，模塊定義方式的語義不順暢

實(shí)現(xiàn)：

• RequireJS

?

前端模塊加載

前端期望的模塊系統(tǒng)可以兼容多種模塊風(fēng)格，盡量可以利用已有的代碼，不僅僅只是 JavaScript 模塊化，還有 CSS、圖片、字體等資源也需要模塊化。

前端模塊要在客戶端中執(zhí)行，所以他們需要增量加載到瀏覽器中。

模塊的加載和傳輸，我們首先能想到兩種極端的方式，

一種是每個(gè)模塊文件都單獨(dú)請(qǐng)求，另一種是把所有模塊打包成一個(gè)文件然后只請(qǐng)求一次。

顯而易見，每個(gè)模塊都發(fā)起單獨(dú)的請(qǐng)求造成了請(qǐng)求次數(shù)過多，導(dǎo)致應(yīng)用啟動(dòng)速度慢；一次請(qǐng)求加載所有模塊導(dǎo)致流量浪費(fèi)、初始化過程慢。這兩種方式都不是好的解決方案，它們過于簡(jiǎn)單粗暴。

分塊傳輸，按需進(jìn)行懶加載，在實(shí)際用到某些模塊的時(shí)候再增量更新，才是較為合理的模塊加載方案。

　　　　　要實(shí)現(xiàn)模塊的按需加載，就需要一個(gè)對(duì)整個(gè)代碼庫中的模塊進(jìn)行靜態(tài)分析、編譯打包的過程。

?

所有資源都是模塊

在上面的分析過程中，我們提到的模塊僅僅是指JavaScript模塊文件。然而，在前端開發(fā)過程中還涉及到樣式、圖片、字體、HTML 模板等等眾多的資源。這些資源還會(huì)以各種方言的形式存在，比如 coffeescript、 less、 sass、眾多的模板庫、多語言系統(tǒng)（i18n）等等。

如果他們都可以視作模塊，并且都可以通過require的方式來加載，將帶來優(yōu)雅的開發(fā)體驗(yàn)，比如：

require("./style.css"); require("./style.less"); require("./template.jade"); require("./image.png");

?

靜態(tài)分析

在編譯的時(shí)候，要對(duì)整個(gè)代碼進(jìn)行靜態(tài)分析，分析出各個(gè)模塊的類型和它們依賴關(guān)系，然后將不同類型的模塊提交給適配的加載器來處理。

比如一個(gè)用 LESS 寫的樣式模塊，可以先用 LESS 加載器將它轉(zhuǎn)成一個(gè)CSS 模塊，在通過 CSS 模塊把他插入到頁面的?<style>標(biāo)簽中執(zhí)行。Webpack 就是在這樣的需求中應(yīng)運(yùn)而生。

同時(shí)，為了能利用已經(jīng)存在的各種框架、庫和已經(jīng)寫好的文件，我們還需要一個(gè)模塊加載的兼容策略，來避免重寫所有的模塊。

那么接下來，讓我們開始 Webpack 的神奇之旅吧。

?

轉(zhuǎn)載于:https://www.cnblogs.com/chaixiaozhi/p/8535639.html

總結(jié)

以上是生活随笔為你收集整理的webpack前言：前端模块系统的演进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。