最近有越來越多人踏入「前端工程」這個領域，也有許多人還在觀望，畢竟前端這個戰場也才剛開打沒幾年，現在要說是「戰國時期」也不為過，各種不同的框架、函式庫、工具每隔幾個月就會推出新版本，不然就是出現另一套全新的改良版，說實在的學也學不完。因此，本篇文章的目的就在於提供一個概略性的介紹，雖然無法盡數所有會用到的前端工具，但我把一些常用的都給介紹一遍，讓那些剛踏入前端或目前還在觀望的人一個參考指引。
前端 JavaScript 框架
前端框架百百種，不同的框架自然有不同的設計理念，採用的技術也不同，因此會用到的前端工具自然也就會有所差異，不過總是有些工具都會用到。以下這幾款算是近期比較熱門的框架：
基本上，當前端開發的工作量越來越重，你不太可能繼續用像是 jQuery 這樣的函式庫處理複雜的 UI 與互動，當然不是說用 jQuery 做不出來，而是使用更適當的框架，可以用更有效率、更少的時間來解決問題，而且還能讓程式碼更容易維護與理解，畢竟 Web 的世界絕對不是業主想像的那麼簡單，裡面有非常多的細節與魔鬼需要面對，採用框架來幫我們建構 Web 應用程式絕對是正確的選擇。
當然，要建置一個完整的網站，你不一定要用這些「純前端」的開發框架才能做，通常你也需要搭配部分後端技術，例如撰寫 Web API 等等，才能建構出一個完整的網站。市面上也有許多「後端」或稱之為「全端」的 Web 開發框架可供選擇，讓你用「純後端」的技術就能建置一個完整的網站，例如 ASP.NET MVC、Ruby on Rails、CakePHP 這類的框架。這些「後端」的框架通常包含一部分後端的程式、一部份前端的程式，且前端所需要的 HTML, CSS, JavaScript 可能還是由後端程式所輸出的，多少會包含一部分前端的技術在內，所以才會說是「全端」框架。
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 规范 )
- 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 這套工具徹底解決使用者在不同模組化技術之間做出選擇，無論你用 AMD、CommonJS 或 ES6 Module 的語法他都通通支援，webpack 在轉譯的過程中會自動將載入的模組自動打包成一個或多個 JavaScript 檔案，而且轉譯後的結果可以是 ES3, ES5 或 ES6 語法，因此這些轉譯後的程式可以讓你跑在各種瀏覽器中，也可以跑在 Node.js 環境下。
透過 webpack 這套工具不僅僅可以管理 JavaScript 模組，還可以幫你管理其他可模組化的資源，例如像是 css, png, html, fonts 都可以透過 webpack 的 載入器 (Loaders) 進行格式轉換，讓你可以透過 JavaScript 載入各種不同資源的模組，功能十分強大。
前端 CSS 框架
當前端人員建置的網站越來越複雜，負責網頁樣式的 CSS 也越來越多，缺乏結構化的 CSS 樣式表會帶來許多樣式維護上的困擾，因此市面上也推出許多嘗試解決樣式表管理問題的 CSS 框架，透過 CSS 框架的協助下，你可以更輕鬆的處理各種各式各樣的版面、樣式、字型、跨瀏覽器、跨行動裝置、RWD (Responsive Web Design) 的設計問題，比較常見的 CSS 框架有：
在 CSS Front-end Frameworks with comparison 這個網頁中有各家 CSS 框架的比較表，各位可以參考比較一下在決定用哪一套。
CSS 前置處理器
不只是 JavaScript 需要轉譯器，其實 CSS 也需要轉譯器，只是通常在 CSS 領域中不會稱為「轉譯器」，而稱為「前置處理器」或「預處理器」(Preprocessor)。別小看 CSS 看似容易上手，其實他一點都不簡單，當你的網站頁面越來越多，不同頁面之間的 UI 越來越複雜，你就更需要用更結構化的方式來撰寫 CSS 語法，否則這些龐雜的 CSS 語法有可能會讓你的網站失去控制，可能會在最後導致疊床架屋、檔案又極其肥大的樣式表，也可能會導致頁面顯示效能低落，或是出現樣式的問題卻找不到問題的源頭等等，這些問題對於一個有經驗的前端人來說，應該都是歷歷在目的慘痛經驗。
在前端工程的 CSS 領域中，通常大家會設計出一個格式或語法，然後透過 CSS 前置處理器將一種格式轉換成為標準的 CSS 格式。市面上的 CSS 的前置處理器也不少，常見的有：
一樣的，不同的團隊、不同的開發團隊主管，可能有不同的偏好，所以我沒辦法建議你該用哪一套，只能說「我」個人喜歡 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 有：
這兩套工具都是用 Node.js 寫的，都是用來實作前端工作自動化的工具，Grunt 算是老牌的 JS 建置工具，擁有超過 5000 個外掛模組可用。而 Gulp 則算是較為新潮的建置工具，擁有超過 1,691 個外掛模組可用，但執行效能較好，設定檔的 API 更為淺顯易懂，因此這套算是目前比較受歡迎的建置工具，我個人也愛用這一套。
套件管理器
前端的套件五花八門，光是管理套件的安裝與升級，就有可能耗費你大量的時間，因此學習一套好用的套件管理器也非常重要，目前市面上常見的前端套件管理器有：
- Bower
- bower 是一套專門為了 Web 環境所設計的套件管理器，他會負責安裝與升級，也負責管理套件之間的相依性，讓你再升級套件的時候不至於破壞套件之間的相依關係。例如當你升級 jQuery 的時候，如果跟其他套件有相依性的衝突，bower 就不會自動幫你升級，並提示你升級會發生相依性衝突。
- npm
- npm 是 node package manager 的縮寫，通常用於 Node.js 環境下，用來管理 Node.js 應用程式所需要的模組。
- npm 也有不少人直接拿來當作前端套件的管理器來用，在這種情境下，有些人會選擇不用 bower 管理前端套件。
建模工具
對於一個初學者來說，要從無到有建立一個網站是有點困難的，況且上述這些洋洋灑灑這麼多的前端工具，全部都要學會、都要設定到好，這門檻不知道有多高！就因為這個需求，導致了一種名為 建模工具 (Scaffolding Tool) 的出現，而較為常見的建模工具當然就是 Yeoman 了。
Yeoman 能幫你快速建立起一個網站的骨架，幫你把預設的目錄、檔案、設定全部寫好，讓你不用從頭做起，你只要看得懂這些預先寫好的設定檔即可，大幅降低新手上路的門檻。
Yeoman 其實是一系列工具的組合，分別是：
所以一個前端網站的建置流程，可以這樣設計：
- 先使用 yo 快速建立網站骨架
- 建立骨架的過程中會自動透過 Bower 與 npm 自動安裝相依套件
- 建立完成後可以透過 Grunt 或 Gulp 自動化完成一些預先設定好的工作
文字編輯器
講到前端開發工具，不可避免的就是要挑選一套好用的 文字編輯器 (Text Editor)，這裡講的並不是 整合開發工具 (IDE)，因為 IDE 再怎樣強大，也無法符合前端人的所有需求，不可能把所有的開發情境都列入考量，就算真的做得出這種 IDE 工具，那也肯定非常難用。我們每天要面對那麼多 HTML、CSS 與 JavaScript 的繁瑣細節，沒有好用的文字編輯器絕對無法有效率的工作。
本文稍早提到的「轉譯器」或「前置處理器」，其實都會有相對應的命令列工具程式可供格式轉換，大部分都可以透過 npm 進行安裝，而在一些知名的文字編輯器當中，通常都會有相對應的 外掛 (Plugins) 可用，透過這些外掛可以當你在儲存檔案時，自動進行格式轉換或編譯動作，減少許多人工編譯的麻煩。比較常見前端工程師們會用的文字編輯器有：
每一套文字編輯器都有自己的圈子，有自己的外掛，有各自的擁護者，這種東西一樣很「個人化」，沒人規定一定要用哪套比較好，只要用習慣就好。
結語
你也知道前端的技術多如牛毛，就算每種技術都很簡單，全部兜在一起還是會眼花撩亂、腦袋打結，只要你能有效掌握這些必要的前端工具，不但能大幅提高前端工程師的生產力，增加前端人員的自我價值感，更能大幅減少重複性的工作，讓工作變得更有趣，而且還能不斷做出高品質的網站！