2016 年 JavaScript 技術棧展望

\o"2016年JavaScript技術棧展望-碼農(nóng)網(wǎng)"2016年JavaScript技術棧展望如果你正在籌劃新的前端項目或者重構現(xiàn)有項目，那么你需要認識到現(xiàn)在的前端開發(fā)環(huán)境已經(jīng)今非昔比，這其中有太多的選擇了：React、\o"Flux"Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow……它們的本意是將開發(fā)簡單化，卻無形中提高了學習成本，也給未來項目的維護帶來了不確定性。好在這一現(xiàn)象正在退熱，優(yōu)勝劣汰，優(yōu)秀的項目慢慢沉淀下來，開發(fā)方式也越來越清晰。有些開發(fā)者正在嘗試使用基于上述技術的框架進行開發(fā)，也在一定程度上減少了學習成本。本文中主要介紹了一些我在web應用開發(fā)中所涉及和推崇的技術，其中有一些技術上存在爭議，所以我對于每一技術都只做簡單的介紹和分析。所有的這些觀點都是基于我個人的經(jīng)驗和對社區(qū)的接觸總結而來的，所以各位還請按需各取所用。ReactReact可謂風頭正盛一時無兩：組件化使應用程序更易于開發(fā)和維護學習曲線平緩，核心API簡潔清晰，易于學習JSX語法不落俗套，充分發(fā)揮了JavaScript的能量天生適配Flux和Redux社區(qū)活躍且具有創(chuàng)造力，奉獻了諸多優(yōu)秀的開發(fā)工具單向數(shù)據(jù)流比雙向數(shù)據(jù)綁定的方式更適合復雜應用程序，質量更高支持服務端渲染雖然比起Ember、Aurelia和Angular這些功能豐富的框架，React不是全能手，但React的開發(fā)環(huán)境更加健壯。就目前而言，使用React已經(jīng)不是一個技術選擇，而是一個商業(yè)行為，它能提供更高效和更有效的生產(chǎn)力。當你想開發(fā)移動應用時，因為已經(jīng)學習了React語法，所以可以直接上手ReactNative開發(fā)跨平臺應用。Redux現(xiàn)在，我們已經(jīng)具有了開發(fā)視圖層的能力，接下來，我們需要使用其他工具管理應用程序中的狀態(tài)和生命周期，在這里推薦的工具就是：Redux。為了配合React，F(xiàn)acebook開發(fā)了管理單向數(shù)據(jù)流的工具Flux，雖然Flux基本上實現(xiàn)了對單項數(shù)據(jù)流的支持，但是同時也帶了其他問題，比如如何保存狀態(tài)、何處發(fā)起Ajax請求等等。為了解決這些問題，又衍生了一系列效仿Flux模式的框架：Fluxible、Reflux、Alt、Flummox、Lux、Nuclear、Fluxxor……目前來說被開發(fā)社區(qū)廣泛支持的一個實現(xiàn)就是Redux。在Redux中，大多數(shù)的組件都是純函數(shù)式的組件，也只有一個集中的存儲和資源中心。Redux的實例方法負責整個數(shù)據(jù)的操作和維護。相比Flux來說，Redux的思路更加清晰。更重要的是，Redux非常易于學習。Redux的作者DanAbramov是一個優(yōu)秀的教師，他制作了一系列深入淺出的Redux視頻教程。通過觀看這些視頻，即可成為一個Redux方面的專家。我曾經(jīng)見識到一個零基礎的React團隊在短短幾周內迅速開發(fā)出了測試版產(chǎn)品，且代碼非常穩(wěn)健和老練。Redux周邊的生態(tài)系統(tǒng)和Redux本身一樣健壯。從神奇的

devtool

到強大的記憶化工具

reselect，Redux開發(fā)社區(qū)為開發(fā)者提供了應有盡有的工具。開發(fā)者可能會本能地去嘗試抽象出一個Redux模板，這么做有諸多好處，但請在認清需求的基礎上來封裝模板，而不要盲目的去嘗試。ES6和Babel是時候拋棄CoffeeScript了，這是因為它的諸多特性已在ES6中出現(xiàn)類似的語法，而ES6是實施標準，代表了JavaScript未來的發(fā)展方向。目前最新的瀏覽器已經(jīng)支持了ES6的大部分特性。Babel是一個強大的轉換工具，用于將ES6轉換為ES5。此外，根據(jù)目標瀏覽器可以調整代碼轉換的程度。那么是否有類型系統(tǒng)呢？TypeScript和Flow都為JavaScript提供了靜態(tài)類型系統(tǒng)，使用靜態(tài)類型檢查，可以有效捕獲錯誤，減少測試量。目前來說，我建議對此持觀望態(tài)度。TypeScript在盡力讓JavaScript向C#或Java的方向發(fā)展，但缺少了許多高級的類型系統(tǒng)特性，比如代數(shù)數(shù)據(jù)類型（algebraicdatatypes）。此外，它不能像Flow一樣有效地處理null。相比而言，F(xiàn)low更加強大，捕獲的錯誤類型也更多，但難于配置。此外，它對JavaScript新特性的支持弱于Babel，也不支持Windows系統(tǒng)。就我個人的角度而言，在前端開發(fā)中類型系統(tǒng)并不是至關重要的一環(huán)（此處可能有爭議）。在類型系統(tǒng)更加健壯且對Babel更友好之前，還是讓我們靜觀其變吧。ESLint另一個無可爭議的工具是ESLint。ESLint支持ES6語法，還提供了React插件，已經(jīng)不單單是一個\o"代碼審查工具"代碼審查工具了。目前來說，JSLint已經(jīng)過時了，ESLint可以替代JSHint和JSCS獨樹一幟了。開發(fā)者可以根據(jù)自己的需求配置ESLint，不過在這里我建議根據(jù)

AirBNB的開發(fā)規(guī)范進行配置，也可以直接使用

ESLintairbnbconfig。當然這份規(guī)范中尚有不足之處，但保持團隊整體代碼的一致性，可以有效提高代碼的可讀性。當你熟悉了ESLint之后，建議開發(fā)者深入地嘗試其中的規(guī)則。ESLint捕獲的錯誤越多，產(chǎn)品的穩(wěn)定性越高。NPM，CommonJS和ES6modules忘記Bower吧，用NPM接管一切。類似Browserify和Webpack的構建工具間接提高了NPM在web開發(fā)中的地位。使用NPM，版本管理將會更加簡單，也將更多地與Node.js生態(tài)系統(tǒng)接觸。目前對于CSS的處理尚不足夠完善。你可能會考慮如何在部署服務器上執(zhí)行構建呢？與Ruby的Bundler有所不同，NPM使用了通配符檢索文件，且第三方包可以在代碼開發(fā)中以及項目發(fā)布前做任意修改。使用

shrinkwrap

文件可以凍結項目中的第三方依賴，我建議使用User的shrinkwrap，提高輸出的一致性。此外，開發(fā)者也可以考慮使用類似Sinopia

的工具托管自己的私有NPM服務器。Babel會將ES6module語法轉換為CommonJS。CommonJS是一種歷經(jīng)實踐的語法，這意味著穩(wěn)定和通用，此外，使用類似

treeshaking

（Webpack2.0和Rollup已經(jīng)支持該特性）的機制我們還能實現(xiàn)靜態(tài)代碼分析。Webpack除非你樂意在頁面添加數(shù)百個腳本標簽，否則的話你應該嘗試用構建工具來打包頁面的資源了。此外，你還需要某些工具讓瀏覽器支持NPM第三方包。在這里，我推薦你使用Webpack。一年之前對于上述工作，開發(fā)者還有諸多工具可以選擇，比如基于JavaScript的RequireJS、Browserify和Webpack解決方案，此外還有號稱能對ES6的模塊進行最佳優(yōu)化的RollupJS.在嘗試了所有的工具之后，我強烈建議開發(fā)者選擇Webpack:通過配置可以應對各種情況支持主流的模塊加載方式（AMD，CommonJS，globals）內部機制可以修復破損的模塊可以處理CSS全面的緩存系統(tǒng)支持熱重載可以加載大多數(shù)的資源提供高效的性能優(yōu)化方案Webpack也非常善于處理大型的單頁應用，支持代碼分割和惰性加載。但是值得注意的是，Webpack的學習曲線異常陡峭。不過一旦你學會了它，那么你就掌握了最強大的構建系統(tǒng)。那么Gulp和Grunt呢？相比而言，Webpack更善于處理各類資源。如果你需要執(zhí)行其他類型的構建任務，那么Gulp和Grunt還是有用的。對于類似運行Webpack的基本任務，我建議直接使用

NPM腳本。Mocha+Chai+Sinon在JavaScript中，有大量可選的單元測試工具，每一個都很穩(wěn)定和健壯。如果你只是用于單元測試，那么現(xiàn)有工具完全可以勝任你的需求。常見的測試工具有Jasmine、Mocha、Tape、Ava、Jest等，它們各有所長。我對一個測試框架的要求有如下幾條：可以在瀏覽器運行，便于調試執(zhí)行速度快便于處理異步測試便于在命令行中使用可以兼容任意斷言和數(shù)據(jù)模擬的第三方庫第一條標準就排除了Ava和Jest。我喜歡Chai斷言是因為其種類豐富、功能齊全的插件，喜歡Mocha是因為其對異步的良好支持。強烈建議使用

DirtyChai

避免某些問題。Webpack的

mocha-leader

插件允許開發(fā)者自動執(zhí)行測試。對于React而言，開發(fā)者可以參考一下AirBNB的

Enzyme

和

Teaspoon。我非常鐘愛Mocha的特性，如果你想要的只是最基礎的功能，可以參考這篇文章了解一下Tape。LodashJavaScript并沒有一個類似Java或.NET的核心工具庫，所以開發(fā)者大都會從外部引用一個外部工具庫。目前來說，Lodash是此類工具中的佼佼者。此外，由于它惰性執(zhí)行的特性，也讓它是目前性能最佳的工具之一。使用Lodash時無需引用全部資源，開發(fā)者可以按需使用其中的函數(shù)。在4.x版本中，Lodash為偏愛函數(shù)式編程的開發(fā)者提供了一個“函數(shù)式開發(fā)”模式。如果你熟悉函數(shù)式編程，你可以了解一下

Ramda。如果你決定使用這個庫，可能需要引用一些Lodash函數(shù)。fetch許多基于React的應用程序都不再使用jQuery了。除非你正在維護一個陳舊的項目或者用到的第三方庫依賴了jQuery，否則已經(jīng)沒有必要使用它了。我喜歡讓項目保持簡潔，在代碼中只使用

fetch

。fetch基于promise，F(xiàn)irefox和Chrome都封裝了該接口。對于其他瀏覽器，則需要提供一個膩子腳本。我建議使用

isomorphic-fetch

在各個瀏覽器和服務端保持功能的一致性。當然也可以其他優(yōu)秀的第三方庫異步獲取數(shù)據(jù)，但我覺得fetch已經(jīng)夠用了。同構JavaScript同構JavaScript是指同時運行在客戶端和服務端的JavaScript，常用于在服務端預先渲染頁面，提高性能，便于SEO。使用React可以實現(xiàn)同構JavaScript，但是并不簡單，它提高了程序的復雜度，限制了開發(fā)者可選的工具和第三方庫。如果你正在構建一個B2C的站點，比如電商網(wǎng)站，那么你可能就需要使用同構JavaScript。不過，對于內部站點或者B2B程序，性能就不是最重要的了，則同構JavaScript也就不是太重要了。API最近每個人好像都在思考如何處理API。每個人都在隨波逐流的使用

RESTfullAPI，SOAP

已經(jīng)成為了過去時。目前業(yè)界存在各種API協(xié)議，比如HATEOAS、JSONAPI、HAL、GraphQL等。GraphQL賦予了客戶端進行任意查詢的能力。搭配

Relay，可以更好地處理客戶端的狀態(tài)和緩存。不過，創(chuàng)建GraphQL的服務端接口的難度還較大，且大多數(shù)的文檔都是面向Node.js的。Netflix的

Falcor

看起來提供了和GraphQL/Relay相似的能力，同時還降低了服務端的需求，但它目前尚處于開發(fā)者預覽狀態(tài)，尚未應用于實際開發(fā)。所有已知的規(guī)范都各有缺陷，有些過于復雜，有些只能處理數(shù)據(jù)讀取而不嗯那個更新，有些和REST差異顯著。許多開發(fā)者選擇自己開發(fā)，但是還會遇到上述的問題。我不認為上述有一個完美的解決方案，但我對API有一個自己的認知：可預測，遵循一致性協(xié)議支持在一次查詢中獲取多個實體支持更新操作易于調試易于使用到目前為止，我還沒有發(fā)現(xiàn)滿足上述所有條件的解決方案。如果你正在使用RESFful，建議參考

Swagger

來編寫API。ElectronElectron

可以使用前端技術構建桌面程序，GitHub團隊出品的Atom編輯器就是基于Electron創(chuàng)建的。本質上，Electron內部封裝了一個Node.js，可以打開Chrome窗口渲染UI，還可以訪問操作系統(tǒng)本地的API，并且沒有瀏覽器中的沙盒機制。開發(fā)者可以通過Electron打包和分發(fā)應用程序。這是創(chuàng)建跨平臺軟件最簡單的方式，而且還可以利用上述的所有工具。此外，Electron有完整的文檔和活躍的開發(fā)社區(qū)。你可能聽說過

nw.js

的大名，雖然它已經(jīng)存在了多年，但相比來說，Electron更加穩(wěn)定和易用。這里有一個基于

Electron、React和hotreload的模板，嘗試一下吧。延伸下面是一些我在Twitter上關注的對象：DanAbramov,Redux的創(chuàng)建者ChristopherChedeau,非?；钴S的React開發(fā)者，現(xiàn)就職與FacebookJeffMorrison,Flow的核心貢獻者之一SebastianMarkb?ge,React的創(chuàng)建者之一PeteHuntReact更多值得關注的對象請參考

React