webpack 學習筆記 01 使用webpack的緣由

　　本系列文章實際上就是官網文檔的翻譯加上本身實踐過程當中的理解。

　　

　　伴隨着websites演化至web apps的過程，有三個現象是很明顯的：

1. 頁面中有愈來愈多的Js。
2. 客戶端能作的事情愈來愈多。
3. 愈來愈少的頁面重載(固然也伴隨着更復雜的代碼)。

　　這些現象致使了什麼？大量的前端代碼。　　

　　龐大的代碼庫須要被高效的組織。而Module(組件式)開發的系統即爲大多數開發者採起的途徑。

 

　 MODULE SYSTEM STYLES

　　有不少種定義依賴，導出變量的標準或者說方法：

• <script> tag 的形式(不經過組件系統)      
• CommonJs
• Amd形式
• ES6組件
• 各類其它風格。。　　　　

     

　　<script>tag形式

　　在非組件系統中，咱們的模塊化後的代碼是這樣被組織的。

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

 

　　各個組件向全局變量提供了一個個接口(如：瀏覽器環境的 window對象)。以後，藉助全局對象，咱們就能使用這些組件。

　　痛點

• 全局對象可能會有屬性間衝突(這就是Jquery提供了給$重命名途徑的緣由)
• 咱們須要關心組件加載的順序(先加載依賴項)
• 開發者須要花不少精力來解決依賴問題。
• 在較大的項目中，tag列表將會變得很是的大且難於維護。　　

 

　  CommonJs：同步式的require

　　這種風格的組件系統使用同步的形式來加載依賴項，並返回導出的接口。每個組件能夠藉助exports對象或者配置module.exports來導出接口(Node.js開發者再熟悉不過了)。

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

　　優勢

• 適合用做後端的組件(一次性加載到Cache以重用)
• 已經有了不少此風格的組件(NPM)
• 簡單易用

　　痛點

• 阻塞式，不適合前端。

　　典例

• node.js
• browserify
• modules-webmake
• wreq

 

    AMD：異步式的require

　  AMD的全稱是Asynchronous Module Definition，不少須要用到組建式系統，但又感覺到它們在前端的痛點的開發者建設了AMD。

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

　  優勢

• 異步加載，適合前端環境。
• 並行加載，帶來速度提高。

　　痛點

• 帶來了更多的代碼工做量。

　　典例

• require.js
• curl.js

 

　 ES6組件

　  From EcmaScript6

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

 　 雖然是標準，可是被瀏覽器普遍支持還須要一段時間。

 

　TRANSFERRING

　  組件雖然被執行於客戶端，但不可避免須要經由服務器傳送。

　  關於組件的傳送，有兩個極端：

1. 每一個組件，一個HTTP請求。
   • 優勢：僅僅傳送依賴項。
   • 缺點：請求多，負載高，更慢的啓動延遲。
2. 全部的組件，一個HTTP請求。
   • 優勢：更快，更低延遲。
   • 傳送了不必傳的東西。

　　讓咱們在二者間作一個妥協。在大多數狀況下，如下的方法將更爲適用：

　　－>在編譯全部的組件時，將組件分爲多種批次(chunks or batches)。

　　再某個批次再被須要的時候，再發送他們。

　　解決了前者帶來的請求的高延遲、高負載，後者帶來的無必要信息的傳送。

　　那麼，問題來了，這個分批次由誰來作？

　　webpack。

　　固然，gulp，grunt也是時下很火的可選項。具體工具的選型，仁者見仁，智者見智。 

　　

　 WHY ONLY JAVASCRIPT?

　　組件化系統難道就只能爲javascript服務嗎？前端還須要解決的問題有

• 樣式表
• 圖片
• 字體
• 模版
• coffeescript -> js
• less -> css
• jade -> html
• 各類。。。。。。

　　沒錯，這些，webpack也能搞定

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