如果你正在籌劃新的前端項目或重構現有項目，那麼你需要認識到現在的前端開發環境已經今非昔比，這其中有太多的選擇了：React 、Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow… 它們的本意是將開發簡化，卻無形中提高了學習成本，也為未來專案的維護帶來了不確定性。
好在這現象正在退熱，優勝劣汰，優秀的專案慢慢沉澱下來，開發方式也越來越清晰。一些開發者正在嘗試使用基於上述技術的框架進行開發，並且在一定程度上減少了學習成本。
本文中主要介紹了一些我在 web 應用開發中所涉及和推崇的技術，其中有一些技術上存在爭議，所以我對於每一技術都只做簡單的介紹和分析。所有的這些觀點都是基於我個人的經驗和對社區的接觸總結而來的，所以各位還請按需各取所用。
React 可謂風頭正盛一時無兩：
元件化使應用程式更易於開發與維護
學習曲線平緩，核心API 簡潔清晰，易於學習
JSX 語法不落俗套，充分發揮了JavaScript 的能量
天生適配Flux 和Redux
#社群活躍且有創造力，奉獻了許多優秀的開發工具
單向資料流比雙向資料綁定的方式更適合複雜應用程序，品質更高
支援服務端渲染
#雖然比起Ember、Aurelia 和Angular 這些功能豐富的框架，React 不是全能手，但React 的開發環境更加健壯。就目前而言，使用 React 已經不是一個技術選擇，而是一個商業行為，它能提供更有效率和更有效的生產力。
當你想開發行動應用程式時，因為已經學習了 React 語法，所以可以直接上手 React Native 開發跨平台應用程式。
現在，我們已經具有了開發視圖層的能力，接下來，我們需要使用其他工具管理應用程式中的狀態和生命週期，在這裡推薦的工具就是：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 模板，這麼做有諸多好處，但請在認清需求的基礎上來封裝模板，而不要盲目的去嘗試。
是時候拋棄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 支援 ES6 語法，也提供了 React 插件，已經不單單是一個程式碼審查工具了。目前來說，JSLint 已經過時了，ESLint 可以取代 JSHint 和 JSCS 獨樹一幟了。
開發者可以依照自己的需求配置 ESLint，不過在這裡我建議依照 AirBNB 的開發規格進行配置，也可以直接使用 ESLint airbnb config。當然這份規範中尚有不足之處，但維持團隊整體程式碼的一致性，可以有效提升程式碼的可讀性。
當你熟悉了 ESLint 之後，建議開發者深入嘗試其中的規則。 ESLint 捕捉的錯誤越多，產品的穩定性越高。
忘記 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 已經支援該特性）的機制我們還能實現靜態程式碼分析。
除非你樂意在頁面上新增數百個腳本標籤，否則的話你應該嘗試用建置工具來打包頁面的資源了。此外，你還需要某些工具讓瀏覽器支援 NPM 第三方套件。在這裡，我推薦你使用 Webpack。
一年之前對於上述工作，開發者還有許多工具可以選擇，例如基於JavaScript 的RequireJS、Browserify 和Webpack 解決方案，此外還有號稱能對ES6 的模組進行最佳優化的RollupJS.
在嘗試了所有的工具之後，我強烈建議開發者選擇Webpack:
透過設定可以處理各種情況
#支援主流的模組載入方式（AMD，CommonJS，globals）
內部機制可以修復破損的模組
可以處理CSS
全面的快取系統
支援熱重載
可以載入大多數的資源
提供高效能的效能最佳化方案
Webpack 也非常善於處理大型的單頁應用，支援程式碼分割和惰性載入。
但值得注意的是，Webpack 的學習曲線異常陡峭。不過一旦你學會了它，那麼你就掌握了最強大的建構系統。
那麼 Gulp 和 Grunt 呢？相較而言，Webpack 更善於處理各類資源。如果你需要執行其他類型的建置任務，那麼 Gulp 和 Grunt 還是有用的。對於類似運行 Webpack 的基本任務，我建議直接使用 NPM 腳本。
在 JavaScript 中，有大量可選的單元測試工具，每一個都很穩定且健壯。如果你只是用於單元測試，那麼現有工具完全可以勝任你的需求。
常見的測試工具有 Jasmine、Mocha、Tape、Ava、Jest 等，它們各有所長。
我對一個測試框架的要求有以下幾條：
可以在瀏覽器運行，便於調試
執行速度快
便於處理非同步測試
#便於在命令列中使用
可以相容任意斷言和資料模擬的第三方函式庫
第一條標準就排除了Ava 和Jest。
我喜歡 Chai 斷言是因為其種類豐富、功能齊全的插件，喜歡 Mocha 是因為其對非同步的良好支援。強烈建議使用 Dirty Chai 避免某些問題。 Webpack 的 mocha-leader 外掛程式可讓開發者自動執行測試。
對 React 而言，開發者可以參考一下 AirBNB 的 Enzyme 和 Teaspoon。
我非常鍾愛 Mocha 的特性，如果你想要的只是最基本的功能，可以參考這篇文章來了解 Tape。
JavaScript 並沒有一個類似 Java 或 .NET 的核心工具庫，所以開發者大都會從外部引用一個外部工具庫。
目前來說，Lodash 是這類工具中的佼佼者。此外，由於它惰性執行的特性，也讓它是目前性能最佳的工具之一。使用 Lodash 時無需引用全部資源，開發者可以按需使用其中的函數。在 4.x 版本中，Lodash 為偏好函數式程式設計的開發者提供了一個「函數式開發」模式。
如果你熟悉函數式編程，你可以了解 Ramda。如果你決定使用這個函式庫，可能需要引用一些 Lodash 函數。
許多基於 React 的應用程式都不再使用 jQuery 了。除非你正在維護一個陳舊的專案或用到的第三方函式庫依賴了 jQuery，否則已經沒有必要使用它了。
我喜歡讓專案保持簡潔，在程式碼中只使用 fetch 。 fetch 基於 promise，Firefox 和 Chrome 都封裝了該介面。對於其他瀏覽器，則需要提供一個膩子腳本。我建議使用 isomorphic-fetch 在各個瀏覽器和服務端保持功能的一致性。
當然也可以其他優秀的第三方函式庫非同步取得數據，但我覺得 fetch 已經夠用了。
同構 JavaScript 是指同時運行在客戶端和服務端的 JavaScript，常用於在服務端預先渲染頁面，提高效能，以便於 SEO。使用 React 可以實現同構 JavaScript，但並不簡單，它提高了程式的複雜度，限制了開發者可選的工具和第三方程式庫。
如果你正在建立一個 B2C 的站點，例如電商網站，那麼你可能需要使用同構 JavaScript。不過，對於內部網站或 B2B 程序，效能就不是最重要的了，則同構 JavaScript 就不是太重要了。
最近每個人好像都在思考如何處理 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 可以使用前端技術建立桌面程序，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
如果你的應用程式只有兩三屏，那麼就不需要使用路由系統；如果你正在創建一個單頁應用，那麼甚至不需要Redux，只需要React 自己的state 屬性；如果你正在創建一個簡單的CRUD 程序，那麼你就不需要使用Relay；如果你正在學習ES6，並不需要深入地了解Async/Await 或裝飾器；如果你剛開始學習React，並不需要使用熱重載和服務端渲染；如果你剛接觸Webpack，你就不需要分離程式碼和合併多個資源；如果你剛學到Redux，你不需要理解使用Redux-Form 和Redux-Sagas。
保持簡潔，每次只做一件事！
以上是JavaScript 技術棧展望的詳細介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！
