- 原文地址:Frontend in 2017: The important parts
- 原文做者:Kaelan Cooter
- 譯文出自:掘金翻譯計劃
- 本文永久連接:github.com/xitu/gold-m…
- 譯者:gy134340
- 校對者:tvChan, zhouzihanntu
2017 年發生了不少事,想起來,嗯,確實有點多。咱們都喜歡拿前端開發領域的變化之快開玩笑,而在過去幾年中事實也確實如此。javascript
儘管聽起來可能會有些陳詞濫調,今天我想說事情不同了。css
前端趨於穩定 —— 流行的庫基本上已經獲得了大衆化而不是被競爭者搶去風頭 —— 同時 web 開發變的很棒了。html
這篇文章,我將着眼於大的趨勢來總結今年前端生態中發生的一些重要事件。前端
很難說什麼是下一件大事何時到來,特別是你還在上一件大事之中時。獲取開源工具正確的數據很難,一般狀況下咱們看下面幾個地方:vue
React 16 在 9 月發佈,帶來一個徹底重寫的核心架構,同時沒有任何重大 API 的變化。這個新版本提供了改進的錯誤處理機制 error boundaries,以及支持將渲染樹的一個子部分渲染到另外一個 DOM 節點上。java
React 團隊重寫核心庫是爲了未來更好的支持異步,這是如今的版本作不到的。異步渲染下,React 在渲染大型應用時將不會阻塞主線程。這一計劃是爲了在將來的 React 16 的小版本提供這一可選功能,因此你能夠在 2018 前期待一下這個功能。node
React 在前段時間關於 BSD 協議的爭論後 切換到了 MIT 協議。因爲先前條款的太多限制,致使了不少團隊考慮切換一個備選的 JavaScript 視圖框架。然而,一直有爭論這個是 無依據的, 同時新的專利協議讓 React 的用戶受到了更少的保護。react
在各類 beta 版本發佈以後和候選版本中,Angular 4 於三月發佈了。這個版本的關鍵特性是預編譯 —— 在 build 時編譯而不是 render 時編譯。這意味着 Angular 應用程序再也不須要爲應用程序視圖提供編譯器 ,從而大大減小了包的大小。此版本還改進了對服務器端渲染的支持,併爲 Angular 模板語言增長了許多小的「生活質量」改進。android
在 2017 年,相對 React 來講,Angular 持續丟失份額。雖然 Angular 4 是一個流行的版本,它仍是離年初時的高點很遠。webpack
Angular、React 和 Vue 的 NPM 下載量
來源: npmtrends.com
對 Vue 來講,2017年是偉大的一年,使得它做爲一個前端視圖層的框架與 React 和 Angular 並列。它由於簡單的 API 和全套的企業解決方案而流行。因爲採起相似 Angular 的模版語言和相似 React 的組件化思想,它常做爲這二者之間的折中方案。
Vue 在過去一年裏爆炸式的增加。同時產生了數量至關多的 流行組件庫 和模版項目。
大量的公司也開始採用 Vue —— Vue—Expedia, Nintendo, GitLab 包括不少其餘項目。
在年初,Vue 有 37k GitHub star 和 npm 上每週 52k 的下載量。到 12 月中旬時,它已經有了 76k 的 star 和每週 266k 的下載量,分別是之前的兩倍和五倍。
這對比 React 仍然很蒼白,根據 NPM 的數據 React 有每週 1600k 的下載量。能夠期待 Vue 的繼續高速成長,2018 也許它會成爲最頂級的兩個框架之一。
總結: React 目前領先,可是 Angular 仍在追趕。同時,Vue 能夠感覺到人氣的飆升。
在全面的提議流程完成以後,JavaScript 的 2017 ECMAScript 標準在 6 月發佈,包含一些開創性的特性,好比說異步函數,共享內存和原子操做。
異步函數可讓咱們寫簡潔清晰的異步代碼,它們如今被全部瀏覽器支持,在升級到 V8 5.5 以後,NodeJS 在 v7.6.0 中增長了對它們的支持,在 2016 年底發佈同時帶來了重要的性能和內存優化。
共享內存和原子操做是一個很是重要的特性,但尚未引發足夠的重視。共享內存由 SharedArrayBuffer
構造實現,容許 web workers 在內存中訪問數組中相同的 bytes。 Workers (和主線程) 使用 Atomics
提供的原子操做方法在不一樣執行上下文中安全的訪問內存。SharedArrayBuffer
提供相比較 message 一種相對於對象的傳遞更快的通信方法。
採用共享內存在未來將很是重要,對 JavaScript 應用和遊戲貼近原生的性能意味着 web 平臺將變得及其有競爭力。應用在瀏覽器中能夠變的更加複雜和作更多昂貴的操做,同時不須要犧牲性能或者把任務放在後端。一個真實的共享內存的並行架構對用 WebGL 和 web workers 來開發遊戲的人是很是棒的優點。
截至2017年12月,全部主流瀏覽器都支持這一特性,同時 Edge 在 v16 以後開始支持,Node 不支持 web workers,因此沒有計劃支持共享內存。可是,它們在從新考慮對 worker 的支持,因此仍是有可能在未來找到把這一特性放在 Node 中的方式。
總結: 共享內存讓 JavaScript 的並行計算更加簡單和高效。
WebAssembly (或者 WASM) 提供一種用其餘語言編寫而後編譯成能夠在瀏覽器中執行的方法。這種偏底層的類彙編的語言設計出來用來獲取接近原生的性能。JavaScript 如今能夠經過新的 API 加載 WebAssembly 的模塊。
這個 API 還提供一個可讓 JavaScript 用 WebAssembly 模塊實例,直接讀取和操做內存的內存構造函數, 能夠和 JavaScript 應用高度整合。
全部主流瀏覽器如今都支持 WebAssembly,Chrome 在五月,Firefox 在三月,Edge 在十月。Safari 在第 11 個版本,和 MacOS High Sierra 一同發佈,使用原版本的如今能夠獲取更新。Chrome 安卓版以及 Safari 移動端如今都支持 WebAssembly。
你可使用 emscripten 編譯器將 C/C++ 代碼編譯成 WebAssembly,Rust 和 OCaml 也能夠。同時還有不少種方法將 JavaScript(或者其餘相似的)編譯成 WebAssembly。好比說,Speedy.js 和AssemblyScript使用 TypeScript 來檢測類型,可是添加了低級的類型和基礎的內存管理。
這些項目暫時都尚未在生產環境,同時他們的 API 常常變化。有了把 JS 編譯成 WebAssembly 的願望,人們能夠預知這些項目能夠 在 WebAssembly 的流行中獲取動力。
同時已經有不少有趣的 WebAssembly 項目。有一個針對 C++ 的 虛擬 DOM 實現,容許用 C++ 建立整個前端應用。若是你的項目使用 Webpack,有一個 wasm-loader 就不須要手動的操做 fetch,直接解釋 .wasm
類型的文件。WABT 提供了一堆將二進制和 WASM 二進制的文本格式,打印信息之間轉換的工具,以及 merge .wasm
文件。
預計 WebAssembly 將在將來一年變得更加流行,由於更多的工具已經開發出來,JavaScript社區也在乎識到它的可能性。它如今還在 「試驗」 階段,瀏覽器也剛開始支持。它將成爲優化 CPU 密集型任務和圖像及 3D 處理的好工具。最終,隨着它的成熟,我推測會在平常應用中得到更多的使用案例。
總結: WebAssembly 最終會改變一切,但它如今還很新。
2017 年 JavaScript 包管理工具也發生了鉅變,Bower 持續衰落,被 NPM 替代。它最後的版本是 2016 年 9 月,它的管理者如今官方建議用戶在前端項目裏使用 NPM。
Yarn 在 2016 年 10 月發佈給 JavaScript 包管理帶來革新。雖然它使用 NPM 相同的包倉庫,Yarn 提供了更快的依賴下載,安裝速度和更友好的 API。
Yarn 的 lock 文件能夠確保每次從新 build 後的文件在不一樣機器上老是一致的,同時離線模式即在用戶不聯網狀況下從新安裝包。由於它的受歡迎程度大大增長,成千上萬的項目開始使用它。
GitHub Yarn (紫) 和 NPM (棕). 來源: GitHub Star 歷史
NPM 做爲反擊,帶來了巨大性能改變和 API 完全調整的 v5 版本。同時 Yarn 宣佈了 Yarn Workspaces, 容許跟 Lerna 相似的高級 monorepo 支持。
還有更多除 Yarn 和 NPM 以外的 NPM 客戶端,好比另外一個流行的 PNPM,宣稱它是 「更快,更節省存儲的包管理工具」,不一樣於 Yarn 和 NPM,它保留對全部安裝包的全局緩存,同時向你的軟件包的 node_modules 文件中添加這些符號連接。
總結: NPM 針對 Yarn 的流行迅速的調整本身,他們都很棒。
在過去的幾年裏 CSS 預處理器好比 SASS, Less 和 Stylus 變得很流行,在 2014 年發佈的 [PostCSS] (https://github.com/postcss/postcss) 在 2017 真正的爆發,成爲最流行的 CSS 預處理器。不一樣於其它預處理器,PostCSS 採用與 Babel 相似的插件模塊的方法。在轉換樣式表以外它還提供 linter 和其餘工具。
2017 NPM PostCSS, SASS, Stylus, 和 Less 下載量
來源: NPM 統計數據,2017 年 12 月 15 日
還有一些基於組件開發時使用 CSS 的底層問題須要解決。特別是,全局命名空間讓單個組件的分離樣式開發很困難。讓 CSS 文件在另外一個文件而不是在組件代碼裏意味着佔用更多空間同時在開發中須要引用兩個文件。
CSS 模塊化 經過添加組件單獨的命名空間來分離組件和通用的樣式,這能夠用不一樣的類名來爲每一個類來實現。在相似 Webpack 的構造系統中,這已經成爲廣泛採用的可行的方法,用css-loader 來支持模塊化。PostCSS 有一個支持一樣功能的 插件。可是這種方法仍是把 CSS 文件放在組件代碼以外。
「CSS in JS」 是一個在 2014 年底由一個 Facebook 的 React 開發團隊者 Christopher 在 一個著名的演講 提出,同時衍生出一些更易建立組件化樣式的有影響的庫。目前最流行的解決方法是使用 ES6 tagged template literals 來從 CSS 字符串中建立組件的 styled-components 庫。
另外一個流行的方法是 Aphrodite,使用 JavaScript 對象字面量建立與框架無關的內聯樣式。在 [JavaScript 2017] 調查中,34% 的開發者聲稱他們使用過 CSS-in-JS。
總結: PostCSS 是首選的 CSS 預處理器,可是不少人轉向 CSS-in-JS 的方法
2017年 Webpack 鞏固其領先於前一代 JavaScript 打包工具的地位:
NPM 上 Webpack, Gulp, Browserify, Grunt 的下載量
來源: npmtrends.com
Webpack 2 在今年二月發佈,它帶來好比 ES6 模塊化(不在須要 Babel 轉換 import 語句了)和 tree shaking(刪除無用的代碼)這樣的重要特性,V3 不久後也發佈了,帶來一個 「scope hoisting」 的特性,能夠把全部的 webpack 模塊打包成一個文件,極大的減小了文件體積。
在 6 月,webpack 團隊接到 Mozilla 開源組的受權去開發 WebAssembly 的高級支持。這一計劃最終目的是讓 WebAssembly 和 JavaScript 打包工具能夠深度整合。
在打包領域還有一些與 Webpack 無關的的創新空間,它在流行的同時,開發者也在抱怨配置使用它的困難和對於大型項目優化所須要的一堆插件。
Parcel 是一個有趣的項目,在 12 月上旬引發關注(只用 10 天收穫 10000 star)。宣稱本身速度極快,同時零配置。它經過利用 CPU 的多核心和高效的文件緩存達到目的。它操做抽象語法樹而不是像 Webpack 的字符串。像 Webpack 同樣,Parcel 也打包非 JavaScript 的資源文件,像圖片和樣式表文件。
這個模塊工具展現了一個 JavaScript 社區一般的模式:不停的在開箱即用(集中)與配置一切(分散)之間切換。
咱們從 Angular 到 React/Redux,SASS 到 PostCSS 的轉變中能夠看出這一點。Webpack 與在它以前出現的各類打包及任務處理工具同樣,都是使用許多插件來進行分散配置的解決方案。
事實上,Webpack 和 React 在 2017 由於幾乎同樣的緣由受到抱怨,人們期待開箱即用的解決方案,這很重要。
在 2016 年發佈 Webpack 2 以前,Rollup 引發了你們普遍的關注,引入了一個叫作 tree shaking 的流行功能,這是一種移除不用的代碼的有趣方法。 Webpack 在第二個版本中爲 Rollup 的簽名功能提供了支持這個來回應 Rollup 的簽名特性。Rollup 跟 Webpack 相比不一樣的打包方式,讓總的打包體積更小,同時也不能支持代碼分割這一重要的特性了。
在 4 月 React 的團隊從 Gulp 切換 到 Rollup, 不少人問爲何選擇 Rollup 而不是 Webpack。Webpack 迴應稱推薦 Rollup 做爲庫的開發工具而 Webpack 做爲應用的開發方式這篇文章來解決你們的疑惑。
總結: Webpack 還是最流行的打包工具,但也許不會永遠是這樣。
在 2017 Flow 相對於 TypeScript 來講丟失了大量的份額:
Flow 對比 TypeScript NPM 2017 下載量 2017 來源: NPM 趨勢
雖然這一趨勢在持續了幾年,但在 2017 年加快了步伐,TypeScript 如今是 2017 Stack Overflow 開發者調查中第三受喜歡的語言(Flow 並無在這裏說起)。
TypeScript 勝利的緣由包括:更好的工具(特別是 Visual Studio Code 編輯器),lint 工具(tslint 變的超級流行),更大的社區,更多第三方類型庫,更好的文檔,和更簡單的配置。最先 TypeScript 作爲 Angular 項目的可選語言而逐漸流行,如今已經鞏固了在整個社區的使用度。根據 Google 趨勢,TypeScript 今年流行度上升了一倍。
TypeScript 採起快速開發的方式,這使得它能夠不斷微調類型系統來跟上 JavaScript 語言。它如今支持 ECMAScript 的 iterators, generators, 異步 generators,以及動態 import 特性。你如今能夠根據 TypeScript 的類型接口和 JSDoc 註釋來 檢查 JavaScript 的類型。 若是你使用 Visual Studio Code,TypeScript 如今在編輯器中支持出色的轉換工具,容許重命名變量和自動導入包。
總結: TypeScript 贏了 Flow。
Redux 仍然是 React 項目的首選狀態管理解決方案,在 2017 年整個 NPM 下載量增加了 5 倍:
2017 Redux 在 NPM 的下載量
來源: NPM 趨勢
Mobx 是 Redux 在客戶端狀態管理上有趣的競爭者,不像 Redux, MobX 使用可觀察的狀態對象和一個受 響應式函數式編程 概念啓發的 API。Redux 的不一樣之處在於被傳統函數式編程影響和純函數的支持, Redux 能夠看做經過 action 和 reducer 手動管理狀態的解決方案。Mobx 與之相反,是自動化的狀態管理方案由於觀察者模式在背後作了全部你須要作的。
MobX 對你的數據結構,存儲的數據類型,或者是否是能夠序列化成 JSON 作了一些預設。這些因素使初學者很是容易使用 MobX。
不像 Redux, MobX 不是事務型和肯定型的,這意味着 Mobx 不會自動得到 Redux 在調試和日誌記錄方面的全部優勢。。你不能對整個 MobX 的狀態作快照,意味着一些調試工具像 LogRocket 須要手動監測你的每一個可觀察對象。
像美國銀行、IBM 和 Lyft 這些知名公司已經在使用 Mobx 了。同時也有社區中逐步發展的 的插件,工具和教程。它增加迅速:從年初 50k 的 NPM 下載量到十月份 250k 的下載量。
由於上述的限制,MobX 的團隊將一直努力將 Redux 和 Mobx 在一個叫 mobx-state-tree (或者 MST) 的項目中把它們結合起來。它本質上是一個狀態容器,在後臺使用 MobX 來提供一種方式來處理不可變數據,就像使用可變數據同樣簡單。根本上來講,你的狀態仍是可變的,可是你經過 snapshot 同不可變的狀態複本一塊兒工做。
已經由不少的開發者工具能夠幫助你調試檢查你的狀態樹——Wiretap 和 mobx-devtools 是很好的選擇。由於他們大體採起相同的方式工做,你甚至能夠對 mobx-state-tree 使用 Redux 開發工具。
總結: Redux 還是王者,可是請看一下 MobX 和 mobx-state-tree
GraphQL 是一個能夠實時查詢接口語言,由於數據源的緣由提供更清晰簡潔的語法。不像 REST, GraphQL 提供類型語法,容許 JavaScript 客戶端只查詢他們須要的數據,它多是近些年來接口開發中最大的革新。
雖然 GraphQL 語言標準從 2016 年十月 就沒有改變,但人們對它的興趣與日俱增。在過去的幾年裏,Google 趨勢發現對於 GraphQL 的搜索量 [4 倍的增加],對 JavaScript GraphQL 客戶端 NPM 下載量有 [13 倍的增加]。
當前有不少客戶端和服務端實現能夠選擇,Apollo 是流行的選擇之一,它添加全面的緩存控制和與 React 和 Vue 流行庫的整合。MEAN 是也是一個使用 GraphQL 做爲 API 層流行的全棧開發框架。
在過去的幾年 GraphQL 背後的社區 也是極速發展。它創造了 20 多種語言的服務端實現方式,以及數以千計的教程和啓動項目。有一個很好的 awesome list。
React-starter-kit——最流行的使用 GraphQL 的 React 生態環境中的項目。
總結: GraphQL 正在得到增加動力
微軟新的基於 V8 之上的多線程 JavaScript 運行時庫。NapaJS 提供了一種在 Node 環境運行多線程的方式,在現有 Node 架構下更好的支持 CPU 密集型任務的執行。它提供了一種 Node 多任務模型的備選方案,用一個模塊來實現。如今能夠在 NPM 上像其餘庫那樣下載了。
Napa使用 node-webworker-threads 庫來利用 Node 中的線程與底層語言結合,經過使用添加從工做線程內部使用 Node 模塊系統的能力來無縫的融合 Node 生態鏈。它還提供了不一樣 workers 間通訊的全面的接口,與新發布的共享內存標準很是相似。
這個項目是微軟爲 Node 生態系統應用高性能架構所作的努力。它目前正在被 Bing 搜索引擎做爲後端棧的一部分所使用。
有了微軟這樣的大公司的支持,你能夠對 Node 的長期穩定放心了。看 Node 社區跟隨多線程能夠走多遠將會很是有趣。
近些年來構建工具的重要性日益增加。隨着 Prettier 的首次亮相,代碼格式成爲前端構建過程當中常見的一環。它自稱是一個嚴格代碼的格式化工具,旨在經過解析和重寫來加強始終如一的代碼風格。
當像 lint 工具好比 ESLint 長時間成爲 自動化檢測規則,Prettier 是最富特點的解決方案。不像 ESLint, Prettier 還支持 supports JSON, CSS, SASS, 甚至 GraphQL 和 Markdown。它還提供了與 ESLint 及 常見的編輯器 深度結合的能力。若是咱們對分號意見一致,咱們會很棒。
LogRocket 是一個前端的記錄工具,容許你回放發生在本身瀏覽器上的問題。而不是猜想錯誤發生的緣由,或者問用戶要截圖和日誌文件, LogRocket 讓你重現任務能夠迅速的瞭解哪裏出了問題。它和全部的應用都結合的很好,不管什麼框架,同時有記錄額外的 Redux, Vuex, 和 @ngrx/store 上下文工具。
在記錄 Redux 事件和狀態以外,LogRocket 記錄控制面板,JavaScript 錯誤,堆棧,網絡請求/答覆的頭和主體,瀏覽器元信息和自定義日誌。它還操做 DOM 來記錄頁面中的 HTML 和 CSS,即便對最複雜的單頁應用也能夠再現很是精確的錄製畫面。
掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。