2018 前端趨勢：更一致，更簡單

　　2017 是一個前端 Web 開發年。

　　像 React 和 Angular 這樣的框架，繼續在社群中享有大規模的支援，但是，新的候選者 Vue ，人氣也很旺。Webpack 依舊是構建的首選工具，NPM 仍舊是系統選擇包的工具。WebAssembly 以前所未有的速度向 Web 開放了眾多新的和令人興奮的案例。像 GraphQL 等技術，革新了書寫和在 web 應用中使用 API 的方式。

　　於此同時，語言自身也在改進，ECMAScript 標準的 2017 版本增加了非同步功能，這大大提高了開發者寫非同步程式碼時的經驗。現在，它們被所有的主流瀏覽器支援。另一個值得注意的改進是共享記憶體和原子操作。

　　然而， 在暴露出他們出現瀏覽器側通道攻擊涉及推測執行之後，共享記憶體在2月5日被所有的主流瀏覽器暫時禁止 。

　　預計今年某個時候，當瀏覽器的開發商找到的阻止漏洞的方法時，共享記憶體就可以使用了。

　庫和框架

　　React

　　2017年9月，React 16 的釋出賺足眼球。這是迄今為止，React 動靜最大的一個版本：增加了資料塊（fragments，現在可以返回一個陣列，而不是將所有的東西都裝在一個無用的 <div> 元素裡）；更佳的容錯機制（可以顯示錯誤的範圍，出錯時，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 ，即使是最複雜的單頁面應用程式也可以重建畫素完美的視訊。

　　原文地址：https://blog.logrocket.com/what-im-looking-for-from-frontend-in-2018-2f1de300b548