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

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

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

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

在實際應(yīng)用中，往往還需要在服務(wù)端，將所有模塊合并后，再統(tǒng)一加載，這多出了很多工作量

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

注意：

然而基于AMD 規(guī)范的非JavaScript 資源加載有著本質(zhì)的如下缺陷。

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

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

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

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

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

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

這里插入一下es6和CommonJs的區(qū)別：

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

* 
    * 

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

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

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

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

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

構(gòu)建工具完成的目標基本是：

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

fis3的功能和webpack類似，其優(yōu)點是靜態(tài)資源表

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

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

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

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

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

                                                    ***未完待續(xù)***