如果你正在籌劃新的前端項目或者重構現有項目，那麼你需要認識到現在的前端開發環境已經今非昔比，這其中有太多的選擇了：React、Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow…… 它們的本意是將開發簡單化，卻無形中提高了學習成本，也給未來項目的維護帶來了不確定性。
好在這一現象正在退熱，優勝劣汰，優秀的項目慢慢沉澱下來，開發方式也越來越清晰。有些開發者正在嘗試使用基於上述技術的框架進行開發，也在一定程度上減少了學習成本。
本文中主要介紹了一些我在 web 應用開發中所涉及和推崇的技術，其中有一些技術上存在爭議，所以我對於每一技術都只做簡單的介紹和分析。所有的這些觀點都是基於我個人的經驗和對社區的接觸總結而來的，所以各位還請按需各取所用。
React
React 可謂風頭正盛一時無兩：
組件化使應用程序更易於開發和維護
學習曲線平緩，核心 API 簡潔清晰，易於學習
JSX 語法不落俗套，充分發揮了 JavaScript 的能量
天生適配 Flux 和 Redux
社區活躍且具有創造力，奉獻了諸多優秀的開發工具
單向數據流比雙向數據綁定的方式更適合復雜應用程序，質量更高
支持服務端渲染
雖然比起 Ember、Aurelia 和 Angular 這些功能豐富的框架，React 不是全能手，但 React 的開發環境更加健壯。就目前而言，使用 React 已經不是一個技術選擇，而是一個商業行為，它能提供更高效和更有效的生產力。
當你想開發移動應用時，因為已經學習了 React 語法，所以可以直接上手 React Native 開發跨平台應用。
Redux
現在，我們已經具有了開發視圖層的能力，接下來，我們需要使用其他工具管理應用程序中的狀態和生命周期，在這裡推薦的工具就是：Redux。
為了配合 React，Facebook 開發了管理單向數據流的工具 Flux，雖然 Flux 基本上實現了對單項數據流的支持，但是同時也帶了其他問題，比如如何保存狀態、何處發起 Ajax 請求等等。
為了解決這些問題，又衍生了一系列效仿 Flux 模式的框架：Fluxible、Reflux、Alt、Flummox、Lux、Nuclear、Fluxxor……
目前來說被開發社區廣泛支持的一個實現就是 Redux。
在 Redux 中，大多數的組件都是純函數式的組件，也只有一個集中的存儲和資源中心。Redux 的實例方法負責整個數據的操作和維護。相比 Flux 來說，Redux 的思路更加清晰。
更重要的是，Redux 非常易於學習。Redux 的作者 Dan Abramov 是一個優秀的教師，他制作了一系列深入淺出的 Redux 視頻教程。通過觀看這些視頻，即可成為一個 Redux 方面的專家。我曾經見識到一個零基礎的 React 團隊在短短幾周內迅速開發出了測試版產品，且代碼非常穩健和老練。
Redux 周邊的生態系統和 Redux 本身一樣健壯。從神奇的 devtool 到強大的記憶化工具 reselect，Redux 開發社區為開發者提供了應有盡有的工具。
開發者可能會本能地去嘗試抽象出一個 Redux 模板，這麼做有諸多好處，但請在認清需求的基礎上來封裝模板，而不要盲目的去嘗試。
ES6 和 Babel
是時候拋棄 CoffeeScript 了，這是因為它的諸多特性已在 ES6 中出現類似的語法，而 ES6 是實施標准，代表了 JavaScript 未來的發展方向。
目前最新的浏覽器已經支持了 ES6 的大部分特性。Babel 是一個強大的轉換工具，用於將 ES6 轉換為 ES5。此外，根據目標浏覽器可以調整代碼轉換的程度。
那麼是否有類型系統呢？TypeScript 和 Flow 都為 JavaScript 提供了靜態類型系統，使用靜態類型檢查，可以有效捕獲錯誤，減少測試量。目前來說，我建議對此持觀望態度。
TypeScript 在盡力讓 JavaScript 向 C# 或 Java 的方向發展，但缺少了許多高級的類型系統特性，比如代數數據類型（algebraic data types）。此外，它不能像 Flow 一樣有效地處理 null。
相比而言，Flow 更加強大，捕獲的錯誤類型也更多，但難於配置。此外，它對 JavaScript 新特性的支持弱於 Babel，也不支持 Windows 系統。
就我個人的角度而言，在前端開發中類型系統並不是至關重要的一環（此處可能有爭議）。在類型系統更加健壯且對 Babel 更友好之前，還是讓我們靜觀其變吧。
ESLint
另一個無可爭議的工具是 ESLint。ESLint 支持 ES6 語法，還提供了 React 插件，已經不單單是一個代碼審查工具了。目前來說，JSLint 已經過時了，ESLint 可以替代 JSHint 和 JSCS 獨樹一幟了。
開發者可以根據自己的需求配置 ESLint，不過在這裡我建議根據 AirBNB 的開發規范進行配置，也可以直接使用 ESLint airbnb config。當然這份規范中尚有不足之處，但保持團隊整體代碼的一致性，可以有效提高代碼的可讀性。
當你熟悉了 ESLint 之後，建議開發者深入地嘗試其中的規則。ESLint 捕獲的錯誤越多，產品的穩定性越高。
NPM，CommonJS 和 ES6 modules
忘記 Bower 吧，用 NPM 接管一切。類似 Browserify 和 Webpack 的構建工具間接提高了 NPM 在 web 開發中的地位。使用 NPM，版本管理將會更加簡單，也將更多地與 Node.js 生態系統接觸。目前對於 CSS 的處理尚不足夠完善。
你可能會考慮如何在部署服務器上執行構建呢？與 Ruby 的 Bundler 有所不同，NPM 使用了通配符檢索文件，且第三方包可以在代碼開發中以及項目發布前做任意修改。使用 shrinkwrap 文件可以凍結項目中的第三方依賴，我建議使用 User 的 shrinkwrap，提高輸出的一致性。此外，開發者也可以考慮使用類似Sinopia 的工具托管自己的私有 NPM 服務器。
Babel 會將 ES6 module 語法轉換為 CommonJS。CommonJS 是一種歷經實踐的語法，這意味著穩定和通用，此外，使用類似 tree shaking （Webpack 2.0 和 Rollup 已經支持該特性）的機制我們還能實現靜態代碼分析。
Webpack
除非你樂意在頁面添加數百個腳本標簽，否則的話你應該嘗試用構建工具來打包頁面的資源了。此外，你還需要某些工具讓浏覽器支持 NPM 第三方包。在這裡，我推薦你使用 Webpack。
一年之前對於上述工作，開發者還有諸多工具可以選擇，比如基於 JavaScript 的 RequireJS、Browserify 和 Webpack 解決方案，此外還有號稱能對 ES6 的模塊進行最佳優化的 RollupJS.
在嘗試了所有的工具之後，我強烈建議開發者選擇 Webpack:
通過配置可以應對各種情況
支持主流的模塊加載方式（AMD，CommonJS，globals）
內部機制可以修復破損的模塊
可以處理 CSS
全面的緩存系統
支持熱重載
可以加載大多數的資源
提供高效的性能優化方案
Webpack 也非常善於處理大型的單頁應用，支持代碼分割和惰性加載。
但是值得注意的是，Webpack 的學習曲線異常陡峭。不過一旦你學會了它，那麼你就掌握了最強大的構建系統。
那麼 Gulp 和 Grunt 呢？相比而言，Webpack 更善於處理各類資源。如果你需要執行其他類型的構建任務，那麼 Gulp 和 Grunt 還是有用的。對於類似運行 Webpack 的基本任務，我建議直接使用 NPM 腳本。
Mocha + Chai + Sinon
在 JavaScript 中，有大量可選的單元測試工具，每一個都很穩定和健壯。如果你只是用於單元測試，那麼現有工具完全可以勝任你的需求。
常見的測試工具有 Jasmine、Mocha、Tape、Ava、Jest 等，它們各有所長。
我對一個測試框架的要求有如下幾條：
可以在浏覽器運行，便於調試
執行速度快
便於處理異步測試
便於在命令行中使用
可以兼容任意斷言和數據模擬的第三方庫
第一條標准就排除了 Ava 和 Jest。
我喜歡 Chai 斷言是因為其種類豐富、功能齊全的插件，喜歡 Mocha 是因為其對異步的良好支持。強烈建議使用 Dirty Chai 避免某些問題。Webpack 的 mocha-leader 插件允許開發者自動執行測試。
對於 React 而言，開發者可以參考一下 AirBNB 的 Enzyme 和 Teaspoon。
我非常鐘愛 Mocha 的特性，如果你想要的只是最基礎的功能，可以參考這篇文章了解一下 Tape。
Lodash
JavaScript 並沒有一個類似 Java 或 .NET 的核心工具庫，所以開發者大都會從外部引用一個外部工具庫。
目前來說，Lodash 是此類工具中的佼佼者。此外，由於它惰性執行的特性，也讓它是目前性能最佳的工具之一。使用 Lodash 時無需引用全部資源，開發者可以按需使用其中的函數。在 4.x 版本中，Lodash 為偏愛函數式編程的開發者提供了一個“函數式開發”模式。
如果你熟悉函數式編程，你可以了解一下 Ramda。如果你決定使用這個庫，可能需要引用一些 Lodash 函數。
fetch
許多基於 React 的應用程序都不再使用 jQuery 了。除非你正在維護一個陳舊的項目或者用到的第三方庫依賴了 jQuery，否則已經沒有必要使用它了。
我喜歡讓項目保持簡潔，在代碼中只使用 fetch 。fetch 基於 promise，Firefox 和 Chrome 都封裝了該接口。對於其他浏覽器，則需要提供一個膩子腳本。我建議使用 isomorphic-fetch 在各個浏覽器和服務端保持功能的一致性。
當然也可以其他優秀的第三方庫異步獲取數據，但我覺得 fetch 已經夠用了。
同構 JavaScript
同構 JavaScript 是指同時運行在客戶端和服務端的 JavaScript，常用於在服務端預先渲染頁面，提高性能，便於 SEO。使用 React 可以實現同構 JavaScript，但是並不簡單，它提高了程序的復雜度，限制了開發者可選的工具和第三方庫。
如果你正在構建一個 B2C 的站點，比如電商網站，那麼你可能就需要使用同構 JavaScript。不過，對於內部站點或者 B2B 程序，性能就不是最重要的了，則同構 JavaScript 也就不是太重要了。
API
最近每個人好像都在思考如何處理 API。每個人都在隨波逐流的使用 RESTfull API，SOAP 已經成為了過去時。目前業界存在各種 API 協議，比如 HATEOAS、JSON API、HAL、GraphQL 等。
GraphQL 賦予了客戶端進行任意查詢的能力。搭配 Relay，可以更好地處理客戶端的狀態和緩存。不過，創建 GraphQL 的服務端接口的難度還較大，且大多數的文檔都是面向 Node.js 的。
Netflix 的 Falcor 看起來提供了和 GraphQL/Relay 相似的能力，同時還降低了服務端的需求，但它目前尚處於開發者預覽狀態，尚未應用於實際開發。
所有已知的規范都各有缺陷，有些過於復雜，有些只能處理數據讀取而不嗯那個更新，有些和 REST 差異顯著。許多開發者選擇自己開發，但是還會遇到上述的問題。
我不認為上述有一個完美的解決方案，但我對 API 有一個自己的認知：
可預測，遵循一致性協議
支持在一次查詢中獲取多個實體
支持更新操作
易於調試
易於使用
到目前為止，我還沒有發現滿足上述所有條件的解決方案。
如果你正在使用 RESFful，建議參考 Swagger 來編寫 API。
Electron
Electron 可以使用前端技術構建桌面程序，GitHub 團隊出品的 Atom 編輯器就是基於 Electron 創建的。本質上，Electron 內部封裝了一個 Node.js，可以打開 Chrome 窗口渲染 UI，還可以訪問操作系統本地的 API，並且沒有浏覽器中的沙盒機制。開發者可以通過 Electron 打包和分發應用程序。
這是創建跨平台軟件最簡單的方式，而且還可以利用上述的所有工具。此外，Electron 有完整的文檔和活躍的開發社區。
你可能聽說過 nw.js 的大名，雖然它已經存在了多年，但相比來說，Electron 更加穩定和易用。
這裡有一個基於 Electron、React 和 hot reload 的模板，嘗試一下吧。
延伸
下面是一些我在 Twitter 上關注的對象：
Dan Abramov, Redux 的創建者
Christopher Chedeau, 非常活躍的 React 開發者，現就職與 Facebook
Jeff Morrison, Flow 的核心貢獻者之一
Sebastian Markbåge, React 的創建者之一
Pete Hunt
React
更多值得關注的對象請參考 React Influencers
建議閱讀 Pate Hunt 的 Learning React!
Dan Abramov 發布一系列的視頻教程 Getting started with Redux，強烈推薦！此外，Dan 還發布過一個關注列表，比上述更加詳細。
Mark Erikson 的 React/Redux links 集合也是很好的學習材料。
按需使用
JavaScript 的生態環境發展迅速，正日益強大起來。React 的最佳實踐正在固化，周邊工具的職責和能力也日益清晰。
最重要的事情就是要牢記：保持簡潔，按需使用。
如果你的應用程序只有兩三屏，那麼就無需使用路由系統；如果你正在創建一個單頁應用，那麼甚至不需要 Redux，只需要 React 自己的 state 屬性即可；如果你正在創建一個簡單的 CRUD 程序，那麼你就不需要使用 Relay；如果你正在學習 ES6，並不需要深入地了解 Async/Await 或裝飾器；如果你剛剛開始學習 React，並不需要使用熱重載和服務端渲染；如果你剛剛接觸 Webpack，你就不需要分離代碼和合並多個資源；如果你剛剛學習 Redux，你不需要理解使用 Redux-Form 和 Redux-Sagas。
保持簡潔，每次只做一件事！
