摘要：做菜的工具有歷史演變的過程，我們軟件開發的工具也是如此。今天就從前端工具演變來聊聊前端的歷史發展。上面的做法很顯然是存在效率和不方便的問題，在這種情況下前端的工具應運而生。是只被用于管理前端的組件，例如，，的工具，只用在前端。

假如你烘焙過蛋糕（哪怕沒有親自做過，但是也應該聽說過），除了基本的面粉，雞蛋等原材料外，或許你還需要一個電動蛋白打發器，一個烤箱。這是現代的做法，那么在打發器和烤箱發明之前，人們怎么烤蛋糕呢？
沒有打發器，只能手動打發，這樣的弊端是不僅花費時間長，而且你的手可能也要廢掉。沒有烤箱，用炭烤，這樣就會出現溫度不好掌握，或許還得有人一直盯著的問題。

我一直愛把軟件開發想成做菜，原材料就是編程語言，菜單是算法邏輯，而做菜的這些工具也是我們在軟件開發中使用的各種工具。做菜的工具有歷史演變的過程，我們軟件開發的工具也是如此。

只是有些工具，現在被大家廣泛使用，而有些卻只能在一些老文章里面見證他們曾經的輝煌。今天就從前端工具演變來聊聊前端的歷史發展。

摸魚警告：本篇沒有干貨，純粹閑聊。

1：沒有任何工具的純手工時代
最開始的前端開發，只需要掌握HTML + CSS + JavaScript就好，我們要在一個頁面上使用js，除了通過標簽外，還可以把js代碼放到一個js文件，通過在HTML文件引用這個js文件的方式：

但是，當我們的業務需求變復雜，項目變大，我們通常會把邏輯相關的代碼都放同一個js文件里面，這樣慢慢就形成了模塊的概念，例如你在做一個超市收銀系統，項目里有一個（或者幾個）js文件是跟價格計算相關，有些js文件是跟時間格式化相關。現在你正在開發收銀小票功能模塊，毋庸置疑，這個模塊肯定需要用到前面的價格計算和時間格式化模塊。這里，就產生了模塊訪問模塊的需求。

很多語言都天然地支持在A文件里面引用B文件的功能，但是javaScript一開始卻不是這樣。因為javaScript一開始是被設計來只在瀏覽器（準確地說是用戶的瀏覽器）上運行的語言。處于安全性的考慮，它不被賦予訪問文件的權利和功能。

在這個階段我們要做到在A文件使用B文件提供的功能，只能在HTML文件里面引用相關的js文件，通過在全局暴露相關變量，然后這樣就能使用到了。

2：包管理（package management）工具
在上面第一點我們提到了模塊。在一個稍大的項目中，一般會用到很多前端社區已經成熟的模塊和框架。比如，專門用來處理時間格式問題的moment.js，以前可能會用到jQuery等。我們要在項目里面使用他們，得先找到他們在網絡上的地址，把相應的文件下載下來，放到我們自己的項目某個目錄，然后再在HTML文件里面引用相應的文件路徑。

上面的做法很顯然是存在效率和不方便的問題，在這種情況下前端的package management工具應運而生。
我們先來了解一下包管理工具為我們做了什么事：
1：幫我們從網絡上下載依賴
2：管理依賴的版本
3：有的還具備task runner功能（npm）
這里就要提到幾個包管理工具：

bower

npm

yarn

bower和npm都是包管理工具，但是又有不同。現在大家聽得最多，用的的可能是npm，yarn，bower已經差不多死掉了。

npm vs bower

npm(node package manager)本是nodejs用來管理node依賴的，但是后來也被用于前端的依賴管理。
bower是只被用于管理前端的組件，例如html，css，js的工具，只用在前端。

在依賴結構上二者也不相同。bower是扁平的依賴樹，需要用戶管理依賴的依賴。而npm采用的是嵌套的依賴樹，不需要用戶關心依賴的依賴。

bower

bower init //創建bower.json
bower install jquery --save //安裝jquery依賴

安裝成功之后會，bower會在當前目錄下創建一個名叫bower_components/的文件夾。所以通過bower安裝的依賴都會放到這個目錄下。例如上面的jquery安裝成功之后，我們能在bower_components/目錄下得到jquery相關文件，然后我們就可以在HTML文件里面引用了:

npm也是類似的：

npm init //創建package.json文件
npm install jquery --save //安裝jquery依賴

安裝成功之后會，npm會在當前目錄下創建一個名叫node_modules/的文件夾。所以通過npm安裝的依賴都會放到這個目錄下。例如上面的jquery安裝成功之后，我們能在node_modules/目錄下得到jquery相關文件，然后我們就可以在HTML文件里面引用了:

3：Module bundler工具
在上面的第二點里面，我們使用了包管理工具，已經不再需要我們自己手動去網上找依賴，下載到項目庫里，但是想要使用，依然需要在HTML文件里面一一引用。我們要怎樣才能像別的語言一樣在一個js文件里面引用另外一個js文件（模塊）呢？

當然自從ES6(ES2015)開始，JavaScript已經有這個功能了，我們可以通過import來引入，export來導出。但是在這之前，我們只能依賴Module bundler工具來做到這一點。

當時比較出名和流行的一下2大解決方案：

CommonJs - node.js, Browserify.js

AMD(Asynchronous Module Definition)- Require.js

至今仍然有很多人沒有弄明白CommonJS和AMD都是一個協議標準，而不是一個具體的庫。CommonJs的核心就是module(模塊)，定義了JavaScript代碼怎樣引用和導出代碼。實現了CommonJs的最出名的就是node.js和Browserify.js，而對應的實現了AMD的比較是Require.js

大家都知道node.js是運行在服務端的JavaScript，不屬于我們本篇的范疇，這里不講。接下來我們來看看

Browserify.js

如果你打開Browserify的官網，可以看到這樣一句話：

Browserify lets you require("modules") in the browser by bundling up
all of your dependencies.

Browserify提供require()方法在一個js文件里面引入另外一個js文件或者一個js文件export的變量。最終Browserify會根據依賴關系，把所有的js代碼都整合到一個js文件里，也就是我們常說的bundle文件。之后就只需要在HTML文件里面引用這一個js bundle文件就行了。

接下來看看具體怎么使用：

step1: 全局安裝browserify

npm install browserify -g //全局安卓browserify

step2: 在module/目錄下創建一個module.js，有如下示例代碼：

function getSum(a, b) {
    return a + b;
}

module.exports = getSum;

step3: 創建main.js文件，在這里面使用module/module.js

var getSum = require("./module/module");
var sum = getSum(10, 10);
console.log("10 + 10 = ", sum);

step4: 利用browserify創建bundle文件：

browserify main.js -o build/bundle.js -d

上面的命令就是：browserify以main.js為源文件，生成bundle文件bundle.js，創建文件夾build/，并把bundle.js放到build/路徑下。-o(-output)表示后面跟上輸出文件路徑， -d表示生成source map.

step5: 在HTMl文件里面引入上一步的bundle.js

step6: 驗證結果

10 + 10 =  20 //控制臺得到我們正確地結果

4：task runner工具
前端的task可能會有：檢查代碼格式，預編譯，跑測試，壓縮代碼，起server等。Task Runner就是按照用戶自定義的任務流自動地完成一系列的task。

一般task runner工具本身并不具體具體執行某項任務的功能，而是每一個任務都有相應的插件來完成。例如曾經流行過的grunt和gulp。

但是現在的前端項目也不會再用到grunt和gulp了。現如今，因為項目上一般會用到npm來做依賴管理，而npm自己的script就可以用來run task, 這樣也不用額外再多下一個額外的工具了。