2016 年 JavaScript 技術棧展望

pinggod發表於2016-03-20
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 上關注的物件：

建議閱讀 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。

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

相關文章