转载

前端工程師必須學會的現代化前端開發工具

最近有越來越多人踏入「前端工程」這個領域，也有許多人還在觀望，畢竟前端這個戰場也才剛開打沒幾年，現在要說是「戰國時期」也不為過，各種不同的框架、函式庫、工具每隔幾個月就會推出新版本，不然就是出現另一套全新的改良版，說實在的學也學不完。因此，本篇文章的目的就在於提供一個概略性的介紹，雖然無法盡數所有會用到的前端工具，但我把一些常用的都給介紹一遍，讓那些剛踏入前端或目前還在觀望的人一個參考指引。

前端 JavaScript 框架

前端框架百百種，不同的框架自然有不同的設計理念，採用的技術也不同，因此會用到的前端工具自然也就會有所差異，不過總是有些工具都會用到。以下這幾款算是近期比較熱門的框架：

AngularJS
ReactJS
Backbone.js
KnockoutJS
Ember.js

基本上，當前端開發的工作量越來越重，你不太可能繼續用像是 jQuery 這樣的函式庫處理複雜的 UI 與互動，當然不是說用 jQuery 做不出來，而是使用更適當的框架，可以用更有效率、更少的時間來解決問題，而且還能讓程式碼更容易維護與理解，畢竟 Web 的世界絕對不是業主想像的那麼簡單，裡面有非常多的細節與魔鬼需要面對，採用框架來幫我們建構 Web 應用程式絕對是正確的選擇。當然，你也不一定要選擇所謂「純前端」的開發框架，市面上也有許多「後端」，或稱之為「全端」的 Web 開發框架可以選擇，例如 ASP.NET MVC 、 Ruby on Rails 、 CakePHP 這類的框架。

JS 轉譯器工具

我們先來說說針對這些 JavaScript 框架有什麼可能會用到的工具，我們都知道 JavaScript 這時幾年來經歷了幾個版本，而訂定 JavaScript 的規格稱為 ECMAScript ，你從 ECMAScript - Wikipedia, the free encyclopedia 可以看到不同版本之間的演進，早期 ECMAScript 3 (ES3) 被實作於 IE6，ECMAScript 4 (ES4) 訂定到一半被放棄，2009 年七月中旬 ECMAScript 5 (ES5) 正式發佈，這版加入了許多功能，也是目前市面上最普及、最多瀏覽器實作的版本，而今年 2015 年的六月則正式推出最新版的 ECMAScript 2015 (ECMAScript 6) (ES6) (ES2015) (ES Harmony)，這個版本可以算是 JavaScript 的大躍進，多出了一大堆功能，有興趣了解 ES6 的人可以到看看由大陸知名技術人阮一峰所寫的《 ECMAScript 6入门》線上電子書，這裡有針對 ES6 非常完整的解說。

ES6 有非常多新推出的 JavaScript 語言特性，對於 JavaScript 原本就不太熟悉的前端工程師來說，ES6 的加入無疑是又多一層學不完的陰霾，只能用「現在客戶的瀏覽器還沒支援 ES6 語法」來含混帶過，等到不得已才要學的時候再說，不過當你看完這篇文章後可能會有所改觀。

正因為市面上的瀏覽器版本不一，難道前端工程師只能屈就於客戶的瀏覽器環境而選擇舊版的 ES3 或 ES5 進行開發嗎？不是這樣的，其實市面上老早就有一種所謂的 轉譯器 (transpiler) 工具出現，他能幫助前端工程師在撰寫程式時直接使用最新版本的 ES5 或 ES6 進行開發，然後透過 transpiler 工具自動幫你轉換成 ES3 的語法格式。

※ 這裡的 transpiler 其實是 transfer (轉換) + compiler (編譯) 的合體字，中文可以翻譯成「轉譯器」。

市面上 轉譯器 (transpiler) 有蠻多的 ( ECMAScript 6 Tools )，有些還會自己創造新的語法，讓你用更簡潔的語法來撰寫程式，並在最後產生 ES3 或 ES5 相容的 JavaScript 程式碼。常見的轉譯器有：

TypeScript

由微軟推出的一套全新語言與工具，這套語言本身為 JavaScript 的超集合 (superset)，最終可將 TypeScript 編譯為 JavaScript 語法。

Babel

可輸入 ES6, ES7 的 JS 程式碼，並自動編譯為 ES3, ES5, ES6 的語法。是一個 JS to JS 轉譯器。

JSX (React)

由 Facebook 所研發出來的一種 XML 語法，用以擴充 ECMAScript 的規格，讓 XML/HTML 可以融合在 JavaScript 程式碼之中，一般用於 React 框架之中。

CoffeeScript

自訂一套極簡的 JS 撰寫風格，最終可將 CoffeeScript 編譯為 JavaScript 語法。

不同的團隊、不同的開發團隊主管，可能有不同的偏好，所以我沒辦法建議你該用哪一套，只能說「我」個人喜歡 TypeScript 與 Babel 而已，在某些情況下 TypeScript 與 Babel 你只需要學寫一套即可，從 TypeScript 1.5 開始，也納入了很多 ES6 語法，所以寫起來蠻相近的，但很多時候我們會需要上網參考別人的寫法時，可能對方用的是一個你從未學過的轉譯器語法，這時多學一點就會比較有幫助。我個人認為，大部分的情況都是用到在學即可，只要對每一套工具有點概念即可，不用真的要樣樣精通。

JS 品質管理工具

JavaScript 寫得好不好、對不對、有沒有符合規範，光用肉眼去看是不夠的，你要用人工去測試出所有可能潛在的 Bugs 也幾乎不太可能，那樣耗費的人力成本太高了。因此，採用適當的 JS 品質控管工具變的日益重要，目前市面上比較常見的品管工具有：

JSHint , a JavaScript Code Quality Tool
ESLint - Pluggable JavaScript linter
JSLint :The JavaScript Code Quality Tool
JSCS : JavaScript Code Style checker

JSHint 是老牌的 JavaScript 品質檢測工具，在許多開發工具與編輯器中都有內建，與 ESLint 或 JSLint 的功能相近，都是用來檢查 JavaScript 的程式碼品質，並自動提供建議，不過比較建議使用 ESLint ，他不但可以檢查 ES5, ES6 的程式碼，他還能檢查 React 的 JSX 語法。

JSCS 則是用來檢測 JavaScript 的程式碼撰寫風格是否符合標準，強迫所有開發成員都要用一致的撰寫風格寫 Code，他還能自動修正你的 JavaScript 程式碼符合規則定義。

上述工具都可以搭配版控與建置工具自動執行。

模組化管理工具

導入前端工程之後，前端工程師需要面對的 JavaScript 越來越多，除了最基本的 JavaScript 語言特性必須了解外，管理龐大的 JavaScript 程式碼變成一種挑戰，你必須透過模組化技術封裝你的 JavaScript 程式，將複雜的細節隱藏，並且降低程式碼之間的相依性，否則光靠 JavaScript 的全域變數來交換資料，當程式碼變多的時候，就會帶來程式無法維護 (或不敢維護) 的窘境。

目前來說，撰寫模組化的 JavaScript 有以下三種選擇：

AMD ( Asynchronous module definition - Wikipedia, the free encyclopedia )

AMD 是一套非同步模組化定義的規格，請注意，這是一份 API 規格，並非實作。
AMD 顧名思義，他是採用「非同步」的方式載入相依模組。
RequireJS 則是一套實作 AMD API 的函式庫，可用於瀏覽器環境。

CommonJS ( CommonJS - Wikipedia, the free encyclopedia )

CommonJS 是一套用於瀏覽器之外的模組化載入規格，已實作於 Node.js 執行環境中。
CommonJS 採用「同步」的方式載入相依模組

ECMAScript 2015 (ECMAScript 6) (ES6) (ES2015) (ES Harmony)

新版 ES6 內建了模組 ( Module ) 功能，進一步將模組化能力加入到 JavaScript 語言特性中。
未來新版的瀏覽器將內建 ES6 模組化能力，不過要等 ES6 Module 可以跑在所有瀏覽器中，可能還有一段時間要等。

市面上有這麼多種不同的模組化規格，前端工程師到底該如何選擇呢？畢竟瀏覽器 (前端) 用到 JavaScript，伺服器 (後端) 也可能用到 JavaScript ( Node.js )，如果你想要將一段寫好的 JavaScript 模組共用在前端與後端，那就麻煩了，因為 CommonJS 無法用在瀏覽器端，而 AMD 這份規格的 API 又相對複雜一些，支援 ES6 的瀏覽器又還沒有完全普及，這該怎麼辦才好呢？是的，針對這個問題，有一套前端工具正好解決了這個問題，那就是最近特別火熱的 webpack module bundler 工具。

webpack 這套工具徹底解決使用者在不同模組化技術之間做出選擇，因為這透過 webpack 這套 轉譯器 (transpiler) 可以幫你把現有的 JavaScript 程式碼使用到的相關模組，無論你用 AMD, CommonJS 或 ES6 Module 的語法他都通通支援， webpack 在轉譯的過程中會自動將載入的模組自動打包成一個或多個 JavaScript 檔案，而且轉譯後的結果可以是 ES3, ES5 或 ES6 語法，因此這些轉譯後的程式可以讓你跑在各種瀏覽器中，也可以跑在 Node.js 環境下。

前端 CSS 框架

當前端人員建置的網站越來越複雜，負責網頁樣式的 CSS 也越來越多，缺乏結構化的 CSS 樣式表會帶來許多樣式維護上的困擾，因此市面上也推出許多嘗試解決樣式表管理問題的 CSS 框架，透過 CSS 框架的協助下，你可以更輕鬆的處理各種各式各樣的版面、樣式、字型、跨瀏覽器、跨行動裝置、RWD ( Responsive Web Design ) 的設計問題，比較常見的 CSS 框架有：

Bootstrap 3
Bootstrap 2
Foundation
Susy
Pure
Baseline

在 CSS Front-end Frameworks with comparison 這個網頁中有各家 CSS 框架的比較表，各位可以參考比較一下在決定用哪一套。

CSS 前置處理器

不只是 JavaScript 需要轉譯器，其實 CSS 也需要轉譯器，只是通常在 CSS 領域中不會稱為「轉譯器」，而稱為「 前置處理器 」或「 預處理器 」(Preprocessor)。別小看 CSS 看似容易上手，其實他一點都不簡單，當你的網站頁面越來越多，不同頁面之間的 UI 越來越複雜，你就更需要用更結構化的方式來撰寫 CSS 語法，否則這些龐雜的 CSS 語法有可能會讓你的網站失去控制，可能會在最後導致疊床架屋、檔案又極其肥大的樣式表，也可能會導致頁面顯示效能低落，或是出現樣式的問題卻找不到問題的源頭等等，這些問題對於一個有經驗的 前端人 來說，應該都是歷歷在目的慘痛經驗。

在前端工程的 CSS 領域中，通常大家會設計出一個格式或語法，然後透過 CSS 前置處理器將一種格式轉換成為標準的 CSS 格式。市面上的 CSS 的前置處理器也不少，常見的有：

Sass (請額外參考《 [前端小字典] Sass 是什麼？》的差異說明)
- Scss (Sassy CSS) ( *.scss ) [新版 Sass 格式]
- Sass ( *.sass ) [ 舊版 Sass 格式 ]
Less
Stylus — expressive, robust, feature-rich CSS preprocessor
PostCSS
Skeleton
Myth

一樣的，不同的團隊、不同的開發團隊主管，可能有不同的偏好，所以我沒辦法建議你該用哪一套，只能說「我」個人喜歡 Sass (Scss) 而已，其他的前置處理器，其語法都還算容��上手，需要時再學即可。

工作管理器

以往在前端開發的過程中，有許多需要手動處理的工作，例如將多個檔案合併、將 JS 或 CSS 檔案進行壓縮、將圖片壓縮、製作 CSS Sprites 圖片、執行 webpack 做模組合併、執行 Sass 或 Less 工具、分析 JavaScript 程式碼品質、執行單元測試、… 等等。你可以發現，每一件工作都有相對應的工具與指令，雖然每個都很簡單，但這些工作都是需要不斷的重複執行，這種工作做久了一定會覺得煩悶，因為這些都是重複性的工作。你當然會說，我把這些工作寫成批次檔不就好了？不過 Windows 下的批次檔不能跑在 Mac OS X 底下，而 Mac OS X 的 Shell Script 無法跑在 Windows 底下，你總不能限制前端工程師只能用 Windows 或 Mac OS X 做開發吧！

這樣的需求，自然會衍生出相對應的工具，這種工具我們通常會稱呼他為 task runner (工作執行器) 或 build tool (建置工具)，而市面上知名的 task runner 有：

Grunt
Gulp

這兩套工具都是用 Node.js 寫的，都是用來實作前端工作自動化的工具， Grunt 算是老牌的 JS 建置工具，擁有超過 5000 個外掛模組可用。而 Gulp 則算是較為新潮的建置工具，擁有超過 1,691 個外掛模組可用，但執行效能較好，設定檔的 API 更為淺顯易懂，因此這套算是目前比較受歡迎的建置工具，我個人也愛用這一套。

套件管理器

前端的套件五花八門，光是管理套件的安裝與升級，就有可能耗費你大量的時間，因此學習一套好用的套件管理器也非常重要，目前市面上常見的前端套件管理器有：

Bower

bower 是一套專門為了 Web 環境所設計的套件管理器，他會負責安裝與升級，也負責管理套件之間的相依性，讓你再升級套件的時候不至於破壞套件之間的相依關係。例如當你升級 jQuery 的時候，如果跟其他套件有相依性的衝突，bower 就不會自動幫你升級，並提示你升級會發生相依性衝突。

npm 是 node package manager 的縮寫，通常用於 Node.js 環境下，用來管理 Node.js 應用程式所需要的模組。
npm 也有不少人直接拿來當作前端套件的管理器來用，在這種情境下，有些人會選擇不用 bower 管理前端套件。

建模工具

對於一個初學者來說，要從無到有建立一個網站是有點困難的，況且上述這些洋洋灑灑這麼多的前端工具，全部都要學會、都要設定到好，這門檻不知道有多高！就因為這個需求，導致了一種名為 建模工具 (Scaffolding Tool) 的出現，而較為常見的建模工具當然就是 Yeoman 了。

Yeoman 能幫你快速建立起一個網站的骨架，幫你把預設的目錄、檔案、設定全部寫好，讓你不用從頭做起，你只要看得懂這些預先寫好的設定檔即可，大幅降低新手上路的門檻。

Yeoman 其實是一系列工具的組合，分別是：

建模工具

工作管理器

Grunt 或 Gulp (二選一即可)

套件管理器

Bower 與 npm

所以一個前端網站的建置流程，可以這樣設計：

先使用 yo 快速建立網站骨架
建立骨架的過程中會自動透過 Bower 與 npm 自動安裝相依套件
建立完成後可以透過 Grunt 或 Gulp 自動化完成一些預先設定好的工作

文字編輯器

講到前端開發工具，不可避免的就是要挑選一套好用的 文字編輯器 (Text Editor)，這裡講的並不是 整合開發工具 (IDE)，因為 IDE 再怎樣強大，也無法符合 前端人 的所有需求，不可能把所有的開發情境都列入考量，就算真的做得出這種 IDE 工具，那也肯定非常難用。我們每天要面對那麼多 HTML、CSS 與 JavaScript 的繁瑣細節，沒有好用的文字編輯器絕對無法有效率的工作。

本文稍早提到的「轉譯器」或「前置處理器」，其實都會有相對應的命令列工具程式可供格式轉換，大部分都可以透過 npm 進行安裝，而在一些知名的文字編輯器當中，通常都會有相對應的外掛 (Plugins) 可用，透過這些外掛可以當你在儲存檔案時，自動進行格式轉換或編譯動作，減少許多人工編譯的麻煩。比較常見前端工程師們會用的文字編輯器有：