2016年JavaScript技術棧展望

 

　　若是你正在籌劃新的前端項目或者重構現有項目，那麼你須要認識到如今的前端開發環境已經今非昔比，這其中有太多的選擇了：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。

 

保持簡潔，每次只作一件事！

 

 

 

連接：http://www.w3cplus.com/javascript/state-of-the-art-javascript-in-2016.html　　　　　　　　　　　譯者：南北

原文：https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.x7l3e5j4t