摘要：以前一直對前端構建工具的理解不深，經過幾天的研究特意來總結一下，第一次寫博客，有寫錯的請多多見諒，該文章我也從其他博客拷了一些內容，如果有冒犯之處，請指出。強大的設計使得它更像是一個構建平臺，而不只是一個打包工具。

以前一直對前端構建工具的理解不深，經過幾天的研究特意來總結一下，第一次寫博客，有寫錯的請多多見諒，該文章我也從其他博客拷了一些內容，如果有冒犯之處，請指出。

如今，網頁不再是自己編寫各種功能了，而是如何把各種不同功能的模塊組合起來。
以前使用script引用不但增加網絡請求，還會時頁面更加臃腫，為了解決這類問題，前端的模塊管理應運而生，最早提出解決方法的是AMD,其實踐方案是requireJs和curlJs.它不僅實現了js文件的異步加載，還管理了模塊之間的倚賴性，（類似于面向對象的Module模式）

main就是主模塊，省略了.js后綴，在main.js里面可以配置模塊的加載，在其頭部寫require.config

在實際應用中，往往還需要在服務端，將所有模塊合并后，再統一加載，這多出了很多工作量

AMD 通過將模塊的實現代碼包在匿名函數（即AMD 的工廠方法，factory）中實現作用域的隔離，通過文件路徑作為天然的模塊ID 實現命名空間的控制，將模塊的工廠方法作為參數傳入全局的define（由模塊加載器事先定義），使得工廠方法的執行時機可控，也就變相模擬出了同步的局部require，因而AMD 的模塊可以不經轉換地直接在瀏覽器中執行。 因此，在開發時，AMD 的模塊可以直接以原文件的形式在瀏覽器中加載執行并調試，這也成為RequireJS 方案不多的優點之一。

注意：

然而基于AMD 規范的非JavaScript 資源加載有著本質的如下缺陷。

1.加載與構建的分離導致plugin 需要分別實現兩套邏輯。
2.在構建產物，r.js構建的結果是define(function(){...})的幾何，文件的執行倚賴頁面上事先引入一個amd模塊加載器（如requireJs自身）,所以常見的AMD項目線上頁面往往存在兩個Javascript文件：loader.js及bundle.js。而browserify和webpack的構建結果 是可以執行的js代碼，它們都支持通過配置生成符合格式的結果文件，如以umd形式暴露 庫的exports，以便其他頁面代碼調用。后者的這種形式更符合js庫的構建
3.瀏覽器的安全策略決定了絕大多數需要讀取文本內容進行解析的靜態資源無法被跨域加載（即使是JavaScript 模塊本身，也要依靠define 方法包裹，類似于JSONP 原理實現的跨域加載）。

其本事不是模塊管理器，只是讓CommondJs格式的模塊可以運行在瀏覽器端，這意味著它可以使用nodeJs的npm模塊管理器。所以，實際上，它等于間接為瀏覽器提供了npm的功能

上面這個代碼使用的是CommondJs格式，無法在瀏覽器中運行，這是需要用到browserify，將上面代碼編譯為瀏覽器腳本

注意：（1）. requirejs/seajs: 是一種在線“編譯”模塊的方案，相當于在頁面上加載一個CommonJS/AMD模塊格式解釋器。這樣瀏覽器就認識了define, exports,module這些東西，也就實現了模塊化。

      （2）.browserify/webpack：是一個預編譯模塊打包的方案，相比于第一種方案，這個方案更加智能。由于是預編譯的，不需要在瀏覽器中加載解釋器。你在本地直接寫JS，不管是AMD/CMD/ES6風格的模塊化，它都能認識，并且編譯成瀏覽器認識的JS。注意： browerify打包器本身只支持Commonjs模塊，如果要打包AMD模塊，則需要另外的plugin來實現AMD到CMD的轉換！！

browserify不支持異步加載，非js文件加載（img src打包路徑問題）

這里插入一下es6和CommonJs的區別：

* 運行時加載: CommonJS 模塊就是對象；即在輸入時是先加載整個模塊，生成一個對象，然后再從這個對象上面讀取方法，這種加載稱為“運行時加載”

* 
    * 

編譯時加載: ES6 模塊不是對象，而是通過 export 命令顯式指定輸出的代碼，輸入時采用靜態命令的形式。即在輸入時可以指定加載某個輸出值，而不是加載整個模塊，這種加載稱為“編譯時加載”

正如我們在前面提到的define 函數的作用，沒有define 函數的CommonJS 模塊是無法直接在瀏覽器中執行的——瀏覽器環境中無法實現同Node.js 環境一樣同步的require 方法。同樣也因為沒有define 與工廠方法，CommonJS 模塊書寫起來要更簡單、干凈。在這個顯而易見的好處下，越來越多的前端項目開始采用CommonJS 規范的模塊書寫方式。

Gulp / Grunt 是一種工具，能夠優化前端工作流程。比如自動刷新頁面、combo、壓縮css、js、編譯less等等。簡單來說，就是使用Gulp/Grunt，然后配置你需要的插件，就可以把以前需要手工做的事情讓它幫你做了。
gulp相比grunt簡便，借助unix的流操作思想，通過管道pipe來管理task任務，實現前端的優化，例如把Js和css融合在一起并壓縮

webpack只是在Loader里面加載的時候，幫我們默認實現了操作，沒有gulp操作得透明，gulp只是構建工具，所以如果開發SPA單頁面應用的時候，需要用到模塊化開發，這時就需要用到模塊化的概念，如果想用CommondJs風格，就需要借助browserify來作為轉換工作，也許你會發現在gulp使用時就有require("gulp")這樣的引用風格，這是npm包管理的模塊，是CommondJs的node的風格，是編寫gulp這些構建工具時用的，不是我們編寫自己的前端模塊代碼的。所以使不使用模塊方案要看項目工程是否龐大決定，如果簡單，做個多頁面應用，不需要把js或各種資源打包處理，只需要簡單的合并，壓縮，在頁面中引用就好，那就不需要Browserify,webpack。用gulp就夠了。使用es6模塊規范時，通過babel轉以后形成commondJs這樣的代碼，一般還不能使用，因為瀏覽器不識別commondJs，所以需要browserify或者webpack將其打包到一個js文件中。

但是相比于npm , grunt和gulp缺點是相當倚賴插件的開發，如果出現新技術時，需要相關人開發插件，如gulp-eslint，當使用時，需要在gulp-eslint文檔和eslint文檔來回切換，不得不在插件和所抽象的工具之間來回切換上下文。相比于npm這個更大的插件社區，缺點教為明顯

構建工具完成的目標基本是：

fis也屬于前端構建工具,它的本質是基于靜態資源標記和動態解析靜態資源表，在模版，js里面使用特殊的標記方法引用前端資源，構建的時候生成一張資源倚賴表，瀏覽器或者后端模版語言在解析的過程中通過查表得到某個靜態資源在不同環境下的引用路徑，所以不管是純前端渲染還是服務端渲染，都容易得到支持，
fis其實是一種靜態資源表的思想，在這種思想下，對于php的smarty產生了fis-plus,基于java的便是 jello，
后來fis3都將其納入了其中

fis3的功能和webpack類似，其優點是靜態資源表

fis3設計之初是用在網頁構建上，所以后端的文件操作之類不適用，fis3的模塊化開發主要是AMD,CMD和自定義擴展commonJs的modJs，三個分別對應于三個插件來實現，由于自己葛璐開發了一種模式，所以導致貢獻也少了,fis可以做到完美的解決方案還需要后端的配合，所以也使得其不了了之。

webpack比較黑盒，用起來很方便，十分適合開發SPA項目，但是卻不適合服務端渲染，webpack目前的功能已經非常齊全，也相應的會帶來首次加載，打包時間慢，需要對其打包進行優化
它既吸取了大量已有方案的優點與教訓，也解決了很多前端開發過程中已存在的痛點，如代碼的拆分與異步加載、對非JavaScript 資源的支持等。強大的loader 設計使得它更像是一個構建平臺，而不只是一個打包工具。

考慮到AMD 規范與CommonJS 規范各有各的優點，且都有著可觀的使用率，webpack 同時支持這兩種模塊格式，甚至支持二者混用。而且通過使用loader，webpack也可以支持ES6 module（這一特性在即將到來的webpack 2 中原生支持），可以說覆蓋了現有的所有主流的 JavaScript 模塊化方案。通過特定的插件實現 shim 后，在webpack 中，甚至可以把以最傳統全局變量形式暴露的庫當作模塊require 進來。

webpack.config.js實在node.js中運行的，因此不支持es6的import語法

其實webpack是個大boss，我就不在本文細說了，網上對webpack的使用已經有很多案例了。
感謝你的捧場，有什么錯誤可以指出，大家多多探討...

                                                    ***未完待續***