2018 前端趨勢：更一致，更簡單
2017 是一個前端 Web 開發年。
像 React 和 Angular 這樣的框架，繼續在社區中享有大規模的支持，但是，新的候選者 Vue ，人氣也很旺。Webpack 依舊是構建的首選工具，NPM 仍舊是系統選擇包的工具。WebAssembly 以前所未有的速度向 Web 開放了眾多新的和令人興奮的案例。像 GraphQL 等技術，革新了書寫和在 web 應用中使用 API 的方式。
於此同時，語言自身也在改進，ECMAScript 標準的 2017 版本增加了非同步功能，這大大提高了開發者寫非同步代碼時的經驗。現在，它們被所有的主流瀏覽器支持。另一個值得注意的改進是共享內存和原子操作。
然而， 在暴露出他們出現瀏覽器側信道攻擊涉及推測執行之後，共享內存在2月5日被所有的主流瀏覽器暫時禁止 。
預計今年某個時候，當瀏覽器的開發商找到的阻止漏洞的方法時，共享內存就可以使用了。
庫和框架
React
2017年9月，React 16 的發布賺足眼球。這是迄今為止，React 動靜最大的一個版本：增加了數據塊（fragments，現在可以返回一個數組，而不是將所有的東西都裝在一個無用的 元素里）；更佳的容錯機制（可以顯示錯誤的範圍，出錯時，React 就會從根元素卸載或者在特殊的出錯範圍組件處卸載）；介面（portals，現在你可以在 React DOM 樹之外的 DOM 節點中展示 React 子元素），還有數據流（streaming，允許伺服器端的 App 向客戶端提供數據流，而不必等待整個序列完成之後才進行）。
此外，React 還採用 RFC 模式，讓 React 開發團隊有機會獲得更多有益的想法。任何會影響到 React API 的 RFC 建議，都可以提交。React 開發團隊發布了他們的語義修改（context changes）建議作為第一個 RFC 的示範。讀起來還挺有意思。
React 粉們已經提供好幾個建議，有些功能非常有趣，包括：
處理方法的參數——減少代碼量，這個建議中，props，state 和 context 都被視為參數。
setState 返回一個承諾（promise）——如果你需要 setState 同步，並且你在一個非同步/等待的環境中，你會發現這對形影不離的鴛鴦對子非常美好。
非同步-安全靜態生命周期鉤子——完全拋棄傳統的、基於類的 API ，讓我們處理起非同步數據來更容易，還能節省不必要的處理步驟，向方法組件提供更潔凈的升級通道。
當然，並不是所有的建議都會出現在未來的版本中。但要承認，React 開發團隊為用戶們做了這些安排，還是很不錯的。隨著 Yarn 和 Ember 等項目的應用展開，RFC 將會變成主流形式。
現代網路開發過程中，設置並協調所有工具相當複雜，所以，Boilerplate 項目在 React 社區內總是受到歡迎。大多數人會建議用戶直接克隆項目文件，就地起爐灶。新手常常茫然不知所措。因為，他們總是會看到一個複雜的「白板」（blank slate），竟然會依賴成千上萬個類庫或軟體，而且他們完全不理解那些配置代碼是什麼意思。
Facebook 的 create-react-app 則不同 —— 它是一個命令行工具，可以將 Webpack、Babel、PostCSS 和 Jest 打包到一起，在零配置情況下的進行開發。自去年以來，它越來越受歡迎。它在 GitHub 中，是一顆閃亮的明星，star 數由 2017 年初的 18k 直接攀升到年底的 40k 。它還提供一個 「eject」（彈射）命令，讓你跳出 create-react-app 模式。那個模式下，依賴軟體自動安裝、配置文件自動生成，你只需要手動修改配置文件。有人說，這個命令的面世也是 React 近年來大受歡迎的部分原因。
對於伺服器端的 React 應用程序，next.js 是個很流行的選擇。它提供了你所需要的「通用的」（universal）網路應用開發工具，安裝、配置起來還挺簡單。在開發難度日益增加，漸進迭代式網路應用（progressive web app）再度受寵，通用的或者同構（isomorphic）的應用降溫的情況下，這一點尤其重要。如果你要新開發一個項目，我鄭重地推薦你使用 next.js 。
我認為，React 社區最終會開發出類似 create-react-app 的東西，但針對的是更為複雜的應用。
next.js 與此目標非常接近。但它只是伺服器端的應用，這就意味著它不會成為主流。在我看來，還沒有哪一個框架已經同時實現即好開發，又好使用。
「附帶電池」（batteries included）的方法將誘惑越來越多的開發者，從而對系統配置的複雜和系統維護所必須花費的時間產生錯覺。
Angular
儘管 Angular 最新的版本（版本 5.1.3 ）已於1月3號發布了，但是 AngularJS 項目（也就是 Angular 1.x 版本 ）仍舊處於活躍的開發狀態，甚至在 2017年12月18號 發布了版本 1.6.8 。許多大公司仍舊使用舊版本的 Angular ，並由於這個原因重要的速度改進和安全修復都移植到了 AngularJS 上。
儘管谷歌對就項目的支持何時結束還不明確，但是在過去的官方說法中已表明對其的支持，在主要的 web 流量轉向 angular.io 而非 angular.org 之前是不會停止的。然而，鑒於舊版本使用的是相當自由的 MIT 協議，儘管官方在2018年不會對其在繼續支持，你也可以期待進一步的發展。
近來 Angular 的發布引起了大家的注意，尤其是最新的 v5 版本的發布。通過如對模板的提前（ahead-of-time）編譯，以及在打包中簡單方便地整合 service worker 這樣創新性的功能，其保持著與其競爭者的與眾不同。
當這些功能對於任何應用程序都是必備的時候，Angular 的閃光之處在於其集成的工具。Angular CLI 簡單易用，並且現在還可以通過 App Shell 提高對快速生成通用的和漸進的 web 應用的支持。
React 社區所秉持的是一種不太固執己見的前端開發哲學。大多數情況下，開發者需要手動安裝許多複雜的功能，除非他們使用 multitude of boilerplate projects 項目中的一種。許多開發者傾向於自己動手設置，這樣他們可以理解系統的各個方面。
有時 web 社區感覺起來是在固執己見和集中化與非固執己見和非集中化之間的輪迴。一件令人不禁思考的事情是 React 社區是否會最終向其他的方向發展。
在完成了幾個大型定義開發的 React / Redux / Webpack 項目後，所有的事情都基本為你準備好了，「馬上開始工作」（just work）是一種極具吸引力的前景。
通過近來發布的版本，可以有趣的看到 Angular 在新的一年中竟會更加受到歡迎。儘管還很難說有多少，但是當你看到 NPM 的下載量的時候，Angular 並沒有看起來增長的那麼多。React 已經繼續保持領先，尤其是在過去的一年中。它目前每天 NPM 的下載量是其他的三倍。
Vue
Vue 在 2017 年已經成了 React 一個非常受歡迎的可替代選項。它們都利用了虛擬 DOM ，並且都是基於組件且超輕量級的。在 JavaScript 2017 調查的描述中，Vue 被列為Angular 1 和 React 之後第三個最常被使用的前端框架。最值得注意的是它還是那次調查中最「想要去學習」的框架。
Vue 的核心團隊計劃 2.6 版本的發布會趕在今年的2月份之前，並將專註於錯誤處理、函數式組件一級服務端渲染。跟隨 React 的引領，他們也計劃在未來的版本中只支持那些基業長青的瀏覽器版本。
Vue 在過去幾年 日漸受歡迎, 但要取代 React 當前前端視圖庫王者的地位，現在看來還很難說。 許多人都寫過它對於來自 Angular 領域的開發者們的吸引力, 而我也期望這種吸引力能繼續保持。通常的觀點是，Vue 不需要你去使用 JSX ，也不像 Angular，它不會強制要求你使用 TypeScript。
它的模板語言也同 Angular 的相當類似。此外，Vue 也有一整套類似 Angular 的聯繫緊密的包，不過 Vue 在以一種更加分散的方式將它們維護得相當好。
模塊打包器
Webpack
Webpack 3 在 2017 年 6 月發布，將作用域的提升（scope hoisting）作為它的旗艦功能。作用域的提升（scope hoisting）將所有模塊一同封裝在一單個閉包中而不是分拆它們。這可以顯著地提升 bundle 的執行時間和 bundle 的體積。 Rollup 是一個顯著的特性，另一個捆綁器模塊已經成為 Webpack 2 及更高版本中功能的靈感來源。
Webpack 團隊已為 Webpack v4 版計划了許多重要的特徵，這是為 alpha 版本寫的博文，預計將會很快發布。最大的特點是 WebAssembly 模塊的支持--目標是使 WASM 模塊作為 ECMAScript 模塊輕易地運行在 Webpack 上。還計劃在生成 CSS 的方式徹底修改 WebPack 。而不是把 CSS 植入 JavaScript 中，Webpack 4 將生成 CSS 資源。
新版本還將專註於構建效率（性能）-- 這是 Webpack 社區投票選出的最優先的 issue 。
在我看來，Webpack 也應該更多地關注文檔和配置信息。雖然 Webpack 的過人之處是配置靈活，但它犧牲了用戶體驗。
一個 Webpack 的 zero-config（零配置）模式已被提出，但它並沒有被優先考慮，儘管像 Parcel 這樣的模塊打包器已經爆炸式地流行。
Parcel
2017 年底，Parcel 大出風頭，在不到一個月的時間裡斬獲 1.4萬 多個 star。它的成功，得益於 Webpack 提供的「零配置」的進展緩慢和混沌不清。它提供了幾個重要的、跟 Webpack 類似的模塊綁定功能，如代碼分割和模塊熱替換。
接下來的開發工作將會集中在補充與 Webpack 類似的小功能上，如進入點（entry point）和一個完備的插件系統。
2018 年我將會密切關注 Parcel 的開發進展。它是否能取代炙手可熱的 Webpack ，讓我們拭目以待。
儘管 Webpack 的最新版本推出了很有價值的功能，新版的用戶文檔網站也進行了大幅的改進，還是讓人感覺到 Webpack 正在走下坡路。
在複雜應用情景下，Webpack 的配置工作仍然是一件頭疼的事。
如果能紓解開發人員的痛苦，提供一個不需要多少配置工作的替代方案，Parcel 定會有所成就。
其他工具
Gulp 和 Browserify 仍然被數以千計的項目以各種形式採用，但不再被認為是前端構建工具的前沿技術。它們的持續開發對於現有系統的維護非常重要，並且它們目前仍然可以用於非常具體的新項目用例。然而，過去幾年開發者的普遍看法是，它們過於複雜，需要過多的手動設置。在 Webpack 應用越來越廣泛佔據領先地位的情況下，他們去年的 NPM 下載量都在持續下滑。
工具
TypeScript
TypeScript 有一個版本計劃在一月發布，包括新的 ECMAScript 功能，例如數字隔離器和幾種涉及對象的文字和類的高級類型系統改進。還有一個改變計劃，是提高 TypeScript 的模塊系統處理非 ECMAScript 模塊的能力。
這將使它更符合 Babel 處理模塊互操作性的方式。希望這可以讓 TypeScript 更容易使用不同類型的模塊，畢竟對新用戶來說是一個致命的痛點。此版本還計劃通過增加對 ECMAScript 模塊自動轉換的支持，來改進已經非常棒的重構功能。
微軟的 TypeScript 顯然在對抗 Flow 上已經贏了（對手是來自 Facebook 的類型檢查工具）。這有很多原因，但在我看來，僅僅是微軟把項目運作得很好。
跟微軟每個月的大量的版本發布相比，Flow 就是零星的小的版本。而且使用 TypeScript 的工具也更好，帶有 tslint 的卓越的 linter 支持和 Visual Studio Code（以及許多其他編輯器）提供的絕妙的編輯器支持，提供了 Flow 不可能實現的自動轉換。
這跟是否是一個更好的類型系統幾乎是無關的。——我敢打賭，大多數開發人員更關心的是支持和易用性。
此外，TypeScript 的社區是很大的。通過 DefinitelyType 項目，TypeScript 提供的流行 NPM 包的類型定義與 flow-typed 提供的類型定義相比，要多很多。如果不出意外，這一事實對任何使用 Flow 的項目的長期生存能力構成嚴重威脅。
移動端
通用 Web 應用程序在 React 出現的時候開始流行起來。這種創新使前端 Web 應用程序能夠以增加開發複雜性為代價在伺服器上先渲染。雖然它們還很是很流行，但它們絕不是真正的做事方式。
在移動端，當前的開發者已經開始專註於開發所謂的漸進式 Web 應用 - 這是最初由 Google 贊助的一項計劃，旨在使 Web 應用對移動端用戶更加友好。對於開發者來說，這意味著更加關注速度和移動端用戶體驗。這可以通過使用像 service workers 來實現離線支持和應用程序清單文件來定製應用在操作系統中的外觀等新技術來實現。這可以被看作是響應式網頁設計的自然演變。
Google 還贊助了加速移動端頁面（Accelerated Mobile Pages，AMP）項目，該項目通過標準化由 Google 提供的緩存式 Web Components 輕量級文檔格式來極大地增加了移動設備上的網頁載入次數。它已經被網路上的主流內容發布商迅速採用，但關於發布商的廣告收入和關於通過在 Google 伺服器上託管內容而放棄控制權的擔憂這兩方面存在持續的爭議。
如果我們希望 Web 繼續保持為一個充滿競爭和吸引力的平台，我們需要與移動端應用競爭。
儘管 漸進式 Web 應用不能做移動端應用可以做的所有事情，但它是維持 Web 長期健康狀況的重要一步。我希望他們變得更受歡迎，最好在不久的將來成為強制性的。
概括總結
總的來說，前端已趨於將現有項目和 Web 開發中許多不同的部分進行整合。React、webpack、TypeScript 繼續變得更受歡迎。Vue 和 Parcel 看起來可能成為各自的領域的領先者的競爭威脅；同時，舊的技術如 Angular 和 Browserify 還在，但以開始緩慢下滑。
一些趨勢仍在繼續，如基於組件的設計。它絕不是一個新概念，它最近開始復興並不局限於 Web 開發。我不希望應用程序架構在短期內發生任何根本性的變化。
有一種傾向於開發者友好的「自以為是」的工具。你可以在反對 Webpack 和 React 的生態系統的複雜性上看到它們。簡單的確勝過複雜，但是沒有複雜度很難滿足各種各樣的需求。
前端發展需要的是更多的共識。人們常常嘲笑它過於複雜，我也有這樣的觀點。
最近的一個重點是吸引新的開發人員，我認為我們也應該關注一般企業 Web 項目中的複雜性——包括應用程序本身和輔助它的構建工具。
插件: LogRocket, 一款適合 Web 應用的 DVR
LogRocket 是一個前端日誌工具，它可以讓你像發生在自己的瀏覽器中那樣重現問題。無需猜測錯誤發生的原因，或者要求用戶截圖以及日誌轉儲，LogRocket 可以讓你重現會話以便快速了解發生了什麼錯誤。無需考慮框架，它適用於任何應用程序，也有插件可以從 Redux、Vuex和@ngrx/tore 上記錄額外的上下文。
除了記錄 Redux 動作和狀態之外，LogRocket 還會記錄控制台日誌、JavaScript 錯誤、堆棧信息、帶有頭+主體的網路請求/響應、瀏覽器元數據和自定義日誌。它還可以指導 DOM 記錄頁面上的 HTML 和 CSS ，即使是最複雜的單頁面應用程序也可以重建像素完美的視頻。
譯者：Tocy, 大別阿郎, Tot_ziens, 南宮冰郁, 亞林瓜子, 無若, LeoXu, 我是菜鳥我驕傲, wilde
譯文：https://www.oschina.net/translate/what-im-looking-for-from-frontend-in-2018
TAG:JavaScript |