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

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

### 前端 JavaScript 框架

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

-   [AngularJS](http://angularjs.org/)
-   [ReactJS](http://reactjs.org)
-   [Backbone.js](http://backbonejs.org/)
-   [KnockoutJS](http://knockoutjs.com/)
-   [Ember.js](http://emberjs.com/)

基本上，當前端開發的工作量越來越重，你不太可能繼續用像是 [jQuery](http://jquery.com/) 這樣的函式庫處理複雜的 UI 與互動，當然不是說用 [jQuery](http://jquery.com/) 做不出來，而是使用更適當的框架，可以用更有效率、更少的時間來解決問題，而且還能讓程式碼更容易維護與理解，畢竟 Web 的世界絕對不是業主想像的那麼簡單，裡面有非常多的細節與魔鬼需要面對，採用框架來幫我們建構 Web 應用程式絕對是正確的選擇。

當然，要建置一個完整的網站，你不一定要用這些「純前端」的開發框架才能做，通常你也需要搭配部分後端技術，例如撰寫 Web API 等等，才能建構出一個完整的網站。市面上也有許多「後端」或稱之為「全端」的 Web 開發框架可供選擇，讓你用「純後端」的技術就能建置一個完整的網站，例如 [ASP.NET MVC](http://asp.net/mvc)、[Ruby on Rails](http://rubyonrails.org/)、[CakePHP](http://cakephp.org/) 這類的框架。這些「後端」的框架通常包含一部分後端的程式、一部份前端的程式，且前端所需要的 HTML, CSS, JavaScript 可能還是由後端程式所輸出的，多少會包含一部分前端的技術在內，所以才會說是「全端」框架。

### JS 轉譯器工具

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

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

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

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

市面上 **[轉譯器 (transpiler)](https://en.wikipedia.org/wiki/Source-to-source_compiler)** 有蠻多的 ([ECMAScript 6 Tools](https://github.com/addyosmani/es6-tools))，有些還會自己創造新的語法，讓你用更簡潔的語法來撰寫程式，並在最後產生 ES3 或 ES5 相容的 JavaScript 程式碼。常見的轉譯器有：

-   [TypeScript](http://www.typescriptlang.org/)
    -   由微軟推出的一套全新語言與工具，這套語言本身為 JavaScript 的超集合 (superset)，最終可將 TypeScript 編譯為 JavaScript 語法。
-   [Babel](https://babeljs.io/)
    -   可輸入 ES6, ES7 的 JS 程式碼，並自動編譯為 ES3, ES5, ES6 的語法。是一個 JS to JS 轉譯器。
-   [JSX (React)](https://github.com/react/jsx)
    -   由 Facebook 所研發出來的一種 XML 語法，用以擴充 ECMAScript 的規格，讓 XML/HTML 可以融合在 JavaScript 程式碼之中，一般用於 [React](http://reactjs.org) 框架之中。
-   [CoffeeScript](http://coffeescript.org/)
    -   自訂一套極簡的 JS 撰寫風格，最終可將 CoffeeScript 編譯為 JavaScript 語法。

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

### JS 品質管理工具

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

-   [JSHint](http://jshint.com/), a JavaScript Code Quality Tool
-   [ESLint](http://eslint.org/) - Pluggable JavaScript linter
-   [JSLint](http://www.jslint.com/):The JavaScript Code Quality Tool
-   [JSCS](https://github.com/jscs-dev/node-jscs): JavaScript Code Style checker

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

[JSCS](https://github.com/jscs-dev/node-jscs) 則是用來檢測 JavaScript 的程式碼撰寫風格是否符合標準，強迫所有開發成員都要用一致的撰寫風格寫 Code，他還能自動修正你的 JavaScript 程式碼符合規則定義。

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

### 模組化管理工具

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

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

1.  [AMD](https://github.com/amdjs/amdjs-api/wiki/AMD) ([Asynchronous module definition - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/Asynchronous_module_definition))
    -   [AMD](https://github.com/amdjs/amdjs-api/wiki/AMD) 是一套非同步模組化定義的規格，請注意，這是一份 API **規格**，並非**實作**。
    -   [AMD](https://github.com/amdjs/amdjs-api/wiki/AMD) 顧名思義，他是採用「**非同步**」的方式載入相依模組。
    -   [RequireJS](http://requirejs.org/) 則是一套實作 AMD API 的函式庫，可用於瀏覽器環境。
2.  [CommonJS](http://www.commonjs.org/) ( [CommonJS - Wikipedia, the free encyclopedia](https://en.wikipedia.org/wiki/CommonJS) ) ( [CommonJS 规范](https://javascript.ruanyifeng.com/nodejs/module.html) )

-   [CommonJS](http://www.commonjs.org/) 是一套用於瀏覽器之外的模組化載入規格，已實作於 [Node.js](http://nodejs.org/) 執行環境中。
-   [CommonJS](http://www.commonjs.org/) 採用「**同步**」的方式載入相依模組
-   有套模組載入工具 [Browserify](http://browserify.org/) 就是採用 [CommonJS](http://www.commonjs.org/) 格式，讓你可以在模組載入後自動產生一個合併後的 JS 檔，由於問世的時間較早，目前使用者也非常多。

4.  [ECMAScript 2015](http://www.ecma-international.org/ecma-262/6.0/) (ECMAScript 6) (ES6) (ES2015) (ES Harmony)
    -   新版 ES6 內建了 **模組** ( Module ) 功能，進一步將模組化能力加入到 JavaScript 語言特性中。
    -   未來新版的瀏覽器將內建 ES6 模組化能力，不過要等 ES6 Module 可以跑在所有瀏覽器中，可能還有一段時間要等。

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

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

透過 [webpack](http://webpack.github.io/) 這套工具不僅僅可以管理 JavaScript 模組，還可以幫你管理其他**可模組化**的**資源**，例如像是 css, png, html, fonts 都可以透過 [webpack](http://webpack.github.io/) 的 **載入器** ([Loaders](https://webpack.js.org/concepts/loaders/)) 進行格式轉換，讓你可以透過 JavaScript 載入各種不同資源的模組，功能十分強大。

### 前端 CSS 框架

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

-   [Bootstrap 3](http://getbootstrap.com/)
-   [Bootstrap 2](http://getbootstrap.com/2.3.2/index.html)
-   [Foundation](http://foundation.zurb.com/)
-   [Susy](http://susy.oddbird.net/)
-   [Pure](http://purecss.io/)
-   [Baseline](http://stephanecurzi.me/baselinecss.2009/)

在 [CSS Front-end Frameworks with comparison](http://usablica.github.io/front-end-frameworks/compare.html) 這個網頁中有各家 CSS 框架的比較表，各位可以參考比較一下在決定用哪一套。

### CSS 前置處理器

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

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

-   [Sass](http://sass-lang.com/) (請額外參考《[\[前端小字典\] Sass 是什麼？](https://www.facebook.com/will.fans/posts/671233282905819)》的差異說明)
    -   Scss (Sassy CSS) ( \*.scss )  \[新版 Sass 格式\]
    -   Sass ( \*.sass ) \[ 舊版 Sass 格式 \]
    -   [Bourbon - A Lightweight Sass Tool Set](http://bourbon.io/)
-   [Less](http://lesscss.org/)
    -   [LESS Hat. A kick-ass LESS Mixin Library for Everyone.](https://github.com/madebysource/lesshat)
-   [Stylus](https://learnboost.github.io/stylus/) — expressive, robust, feature-rich CSS preprocessor
    -   [Cssowl mixin library](http://cssowl.owl-stars.com/)
-   [PostCSS](https://github.com/postcss/postcss)
    -   [PostCSS Mixins](https://github.com/postcss/postcss-mixins)
-   [Skeleton](http://getskeleton.com/)
-   [Myth](http://www.myth.io/)

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

### 工作管理器

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

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

-   [Grunt](http://gruntjs.com/)
-   [Gulp](http://gulpjs.com/)

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

### 套件管理器

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

-   [Bower](http://bower.io/)
    -   bower 是一套專門為了 Web 環境所設計的套件管理器，他會負責安裝與升級，也負責管理套件之間的相依性，讓你再升級套件的時候不至於破壞套件之間的相依關係。例如當你升級 jQuery 的時候，如果跟其他套件有相依性的衝突，bower 就不會自動幫你升級，並提示你升級會發生相依性衝突。
-   [npm](https://www.npmjs.com/)
    -   npm 是 node package manager 的縮寫，通常用於 [Node.js](http://nodejs.org/) 環境下，用來管理 [Node.js](http://nodejs.org/) 應用程式所需要的模組。
    -   npm 也有不少人直接拿來當作前端套件的管理器來用，在這種情境下，有些人會選擇不用 bower 管理前端套件。

### 建模工具

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

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

[Yeoman](http://yeoman.io/) 其實是一系列工具的組合，分別是：

-   建模工具
    -   [yo](https://github.com/yeoman/yo)
-   工作管理器
    -   [Grunt](http://gruntjs.com/) 或 [Gulp](http://gulpjs.com/) (二選一即可)
-   套件管理器
    -   [Bower](http://bower.io/) 與 [npm](https://www.npmjs.com/)

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

1.  先使用 yo 快速建立網站骨架
2.  建立骨架的過程中會自動透過 [Bower](http://bower.io/) 與 [npm](https://www.npmjs.com/) 自動安裝相依套件
3.  建立完成後可以透過 [Grunt](http://gruntjs.com/) 或 [Gulp](http://gulpjs.com/) 自動化完成一些預先設定好的工作

### 文字編輯器

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

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

-   [Sublime Text](http://www.sublimetext.com/3) (跨平台)
-   [Atom](https://atom.io/) (跨平台)
-   [Brackets](http://brackets.io/) (跨平台)
-   [Visual Studio Code](https://code.visualstudio.com/) (跨平台)
-   [WebStorm](https://www.jetbrains.com/webstorm/)  (跨平台) (商用軟體)
-   [Coda](https://panic.com/coda/) (Mac Only)

每一套文字編輯器都有自己的圈子，有自己的外掛，有各自的擁護者，這種東西一樣很「個人化」，沒人規定一定要用哪套比較好，只要用習慣就好。

### 結語

你也知道前端的技術多如牛毛，就算每種技術都很簡單，全部兜在一起還是會眼花撩亂、腦袋打結，只要你能有效掌握這些必要的前端工具，不但能大幅提高前端工程師的生產力，增加前端人員的自我價值感，更能大幅減少重複性的工作，讓工作變得更有趣，而且還能不斷做出高品質的網站！