為什麼要用Webpack

　使用更多 JavaScript

　　更多的使用者介面透過現代瀏覽器提供服務

　　頁面在提供服務的過程中，盡可能少地刷新整個頁面

　　所以現在的網站有盡可能少地刷新整個頁面

　　所以現在的網站有非常多程式碼在運行非常多！龐大的程式碼庫需要被有序地管理起來，而模組系統「Module system」提供一種能力，將程式碼庫切分成一個個模組「Module」

　　模組系統的派別們

　　定義模組及模組依賴的定義模組方法有好幾種標準

<script>標籤「沒有使用模組系統」</script>

CommonJS

AMD

ES6 模組系統🎀㟎方式並沒有使用任何模組系統

各個模組向全域物件「例如，window 物件」匯出一個介面。其他模組透過全域物件存取這個介面。

　　缺點：

　　容易引起衝突

　　需要很注意模組加載的順序

　　模組使用者需要分解模組的依賴🀜度
『〜〜〜在專案模組的依賴度onJS：同步的require 方法

　　這種方式使用同步的require 方法載入一個依賴的模組，並且傳回一個介面。為導出物件「exports」新增屬性 或為 module.exports 賦值，都可以定義模組的導出物件。

　這種方式通常被使用伺服器端NodeJS

　　優點

　　可以利用伺服器度的程式碼

　　npm🜀　　阻塞的載入方式不適用於網路環境，網路請求是非同步的

　　載入多個模組時，沒有平行載入

　　AMD： 非同步的require方法其他應用於瀏覽器環境模組系統，不支援同步的require ，但提供了非同步的require方法其他應用於瀏覽器環境模組系統，不支援同步的require ，但提供了異步require 方法：

　優點

　　符合網路環境下的非同步請求方式

　　多個模組可以平行載入

　　銷
🀜　㟎　　㟎可讀性比較差

　　有點像是一種臨時方案

　　實作：RequireJS

　　ES6 模組系統

　〜ECMAScript 2015「第一個版本

　〜ECMAScript 2015「第6」版本

　　便於靜態分析

　　面向未來的ES 標準

　　缺點

　　瀏覽器支援此特性，還需要一些時間的客觀解決方案

　　讓開發人員選擇模組系統，允許現有的程式碼庫運行“即使它們使用了其他的模組系統”。

　　傳輸

　　模組需要從伺服器傳送到客戶端，才能被客戶端執行。有兩種比較極端的傳輸方式，這兩種方式都被廣泛應用，但都不是最佳的

　　一個模組一次請求

　　所有的模組都在一次請求

　　一個優點一次請求







：只有需要的模組才會傳送

缺點：過多的請求開銷

缺點：請求延遲較大，導致程式開始比較慢



　　一次請求所有模組開銷
比


　　一次請求所有模組開銷
比，延遲較少

缺點：還未使用到的模組，還被下載到客戶端了

　　分片傳輸

　　多數場景下，需要一種更靈活的傳輸方式，它介於以上兩種極端情況之間：

　　當編譯所有模組時，將一系列模組分解成一組小的分片「chunk」

　　相對一次請求所有模組，分片的方式使網路請求變成多個更小，更快的請求。程式啟動時，不需要用到的分片，將會在需要時才載入。

　　相對於一次請求一個模組，這加快程式的初始化，但仍然可以讓你在實際使用時獲取更多的程式碼「減少網路請求開銷」。

　　怎麼分片， 在哪裡分片是由開發者決定的 。大程式碼庫透過這種方式可以組織得很合理。

　　結語

　　針對以上兩大主題， Webpack 支援多種模組系統風格，支援靈活的 chunk 傳輸「Code Split」。

　　Webpack 是一個 JS 模組打包工具，可以用它打包 Web 網站的 JS 程式碼庫，也可以用來打包第三方程式碼庫。不像 RequireJs 只支援 AMD，NodeJS 是 CommonJS， SeaJS 只支援 CMD，如今還有 ES6 Module ... Webpack 像是集大成於一身，開發者在此之上靈活根據自己喜好編碼。