- 原文地址：A comprehensive look back at front-end in 2018
- 原文作者：Kaelan Cooter
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：Ivocin
- 校對者：Junkai Liu, wuzhe
拿一杯咖啡，坐下來，慢慢品讀。我們的回顧不容錯過。
Web 開發一直是一個快速發展的領域 —— 我們很難跟上在過去的一年中所有的瀏覽器變更、函式庫的釋出以及衝擊思維的程式設計趨勢。
前端行業每年都在增長，這使得普通開發者很難跟上。因此讓我們退後一步，回顧一下 2018 年 Web 開發社群發生了哪些變化。
我們目睹了過去幾年 JavaScript 爆炸式的發展。隨著網際網路對全球經濟變得更加重要，谷歌和微軟等巨頭意識到他們需要更好的工具來建立下一代 Web 應用程式。
在這種環境下，以 ECMAScript 2015（又名 ES6）為開端，JavaScript 被引領出自創造以來最大的變革浪潮。現在 JavaScript 每年釋出的版本都為我們帶來了令人興奮的新特性：如類、生成器、迭代器、promise、全新的模組系統等等。
這開啟了 Web 發展的黃金時代。許多最流行的工具、函式庫和框架在 ES2015 釋出後立即流行了起來。即使主流瀏覽器廠商對新標準的支援還未過半，Babel 編譯器專案就讓成千上萬的開發人員搶先一步嘗試新功能。
前端開發者首次不需要被他們公司需要支援的最古老的瀏覽器限制，可以按照自己的節奏自由創新。三年和三個 ECMAScript 版本之後，這個 Web 開發的新時代並沒有放緩前進的腳步。
JS 語言的新特性
與之前的版本相比，ECMAScript 2018 的功能相當簡單，只新增了物件 rest/spread 屬性，非同步 iteration 和 Promise.finally，Babel 和 core-js 現在已經支援了所有這些新特性。大多數瀏覽器和 Node.js 全部都支援了ES2018，除了 Edge，它只支援 Promise.finally。對於許多開發人員來說，這意味著他們所需的所有語言特性都被他們需要相容的瀏覽器支援了 —— 甚至有人懷疑 Babel 是否真的是必需的了。
新的正規表示式特性
JavaScript 一直缺乏像 Python 這樣語言的一些更高階的正規表示式功能 —— 直到現在才推出類似的特性。ES2018 增加了四個新特性：
- 後行斷言（lookbehind assertions），為自 1999 年以來一直使用該語言的先行斷言（ lookahead assertions） 提供了缺失的補充。
- s（dotAll）標誌，它匹配除行終止符之外的任何單個字元。
- 命名捕獲組，通過基於屬性的捕獲組查詢，可以更輕鬆地使用正規表示式。
- Unicode 屬性轉義，可以編寫能夠識別 Unicode 編碼的正規表示式了。
雖然這些新特性中的許多功能多年來都有解決方法和替代庫，但它們都沒有原生實現的速度快。
新的瀏覽器特性
今年釋出了相當多的新的 JavaScript 瀏覽器 API。幾乎所有內容都有所改進 —— 網路安全、高效能運算和動畫等等。讓我們按領域劃分它們以更好地瞭解它們帶來的影響。
WebAssembly
儘管去年對 WebAssembly v1 的支援被新增到了主流瀏覽器中，但它尚未被開發者社群廣泛採用。WebAssembly Group 針對垃圾回收、ECMAScript 模組整合和執行緒等功能提供了巨集大的功能路線圖。也許有了這些功能，我們才會看到 WebAssembly 在 Web 應用程式中被廣泛採用。
有一部分問題是 WebAssembly 需要大量的步驟才能開始使用，而許多習慣於使用 JavaScript 的開發人員並不熟悉使用傳統的編譯語言。Firefox 推出了一個名為 WebAssembly Studio 的線上 IDE，可以讓使用 WebAssembly 變得簡單。如果你希望將其整合到現有的應用程式中，現在有很多工具可供選擇。Webpack v4 為 WebAssembly 模組新增了實驗性內建支援，這些模組緊密整合到構建和模組系統中，並提供 source map 支援。
Rust 已成為編譯 WebAssembly 的最佳語言。它提供了一個健壯的包生態系統，具有 cargo，可靠的效能和易於學習的語法。現在已經有一個新興的工具生態系統將 Rust 與 Javascript 整合在一起。你可以使用 wasm-pack 將 Rust WebAssembly 包釋出到 npm 上。如果你使用了 webpack，現在可以使用 rust-native-wasm-loader 在應用程式中無縫整合 Rust 程式碼。
如果你不想放棄 JavaScript 來使用 WebAssembly，你很幸運 —— 現在有幾種選擇。如果你熟悉 Typescript，可以使用 AssemblyScript 專案，該專案使用官方 Binaryen 編譯器和 Typescript。
因此，它適用於現有的 Typescript 和 WebAssembly 工具。Walt 是另一個堅持 JavaScript 語法的編譯器（使用類似於 Typescript 的型別提示），並直接編譯為 WebAssembly 文字格式。它是零依賴的，具有非常快的編譯速度，並可以與 webpack 整合。這兩個專案都在積極開發中，根據你的標準，它們可能會不適用於生產環境。無論如何，它們都值得一試。
共享記憶體
現代 JavaScript 應用程式經常把大量的計算放在 Web Workers 中，以避免其阻塞主執行緒並中斷瀏覽體驗。雖然 Worker 已經推出幾年了，但它的侷限性使他們無法更廣泛地採用。Worker 可以使用 postMessage 方法在其他執行緒之間傳輸資料，該方法克隆傳送的資料（較慢）或使用可傳輸的物件（更快）。因此，執行緒之間的通訊要麼是慢速的，要麼是單向的。對於簡單的應用程式沒有太大問題，但它限制了使用 Worker 構建更復雜的架構。
SharedArrayBuffer 和 Atomics 是允許 JavaScript 應用程式在上下文之間共享固定記憶體緩衝區並對它們執行原子操作的新功能。但是，在發現共享記憶體使瀏覽器容易受到以前未知的被稱為 Spectre 的定時攻擊後，瀏覽器對該特性的支援被暫時刪除了。Chrome 在 7 月釋出了一項新的安全功能，可以緩解該漏洞，從而重新啟用了 SharedArrayBuffers 功能。在 Firefox 中，該功能預設情況下是禁用的，但可以重新啟用。Edge 完全取消了對SharedArrayBuffers 的支援，微軟尚未表示何時會重新啟用。希望到明年所有瀏覽器都會採用緩解策略，以便可以使用這個關鍵的缺失功能。
Canvas
Canvas 和 WebGL 等圖形 API 已經推出幾年了，但它們一直被限於在主執行緒中進行渲染。因此，渲染可能會阻塞主執行緒。這會導致糟糕的使用者體驗。OffscreenCanvas API 允許你將 canvas 上下文（2D 或 WebGL）的控制權轉移給 Web Worker，從而解決了這個問題。在 Worker 使用 Canvas API 和平時沒有區別，而且不會阻塞主執行緒，並可以無縫渲染。
鑑於顯著的效能提升，可以期待圖表和繪相簿會很快支援它。目前瀏覽器支援僅限於 Chrome 和 Firefox，而 Edge 團隊尚未公開表示支援。你可以期望它能和 SharedArrayBuffers 以及 WebAssembly 很好地配對，允許 Worker 基於任何執行緒中存在的資料，使用任何語言編寫的程式碼進行渲染，所有這些都不會造成糟糕的使用者體驗。這可能使網路上實現高階遊戲的夢想成為現實，而且可以在 Web 應用程式中使用更復雜的圖形。
新的繪圖和佈局 API 正努力被引入 CSS。目標是向 Web 開發人員公開 CSS 引擎的部分內容，以揭開 CSS 的一些“神奇”神祕面紗。W3C 的 CSS Houdini 工作組由主要瀏覽器供應商的工程師組成，在過去兩年中一直在努力釋出幾個規範草案，這些規範目前正處於設計的最後階段。
CSS Paint API 是其中最早登陸瀏覽器的新 CSS API ，它在 1 月份登陸 Chrome 65。它允許開發人員使用類似 context 的 API 繪製影像，可以在 CSS 中呼叫影像的任何地方使用它。它使用新的 Worklet 介面，這些介面基本上是輕量級，高效能的類似 Worker 的構造，用於專門的任務處理。和 Worker 一樣，它們在自己的執行上下文中執行，但與 Worker 不同的是，它們是執行緒不可感知的（瀏覽器選擇它們執行的執行緒），並且它們可以訪問渲染引擎。
使用 Paint Worklet，你可以建立一個背景影像，當其中包含的元素髮生更改時，該影像會自動重繪。使用 CSS 屬性，你可以新增在更改時觸發重新繪製的引數，並可通過 JavaScript 進行控制。所有瀏覽器都承諾支援該 API，除了 Edge，但是現在有一個 polyfill 可以使用。有了這個 API，我們將開始看到元件化影像的使用方式，這與我們現在看到的元件類似。
動畫
大多數現代 Web 應用程式使用動畫作為使用者體驗的重要部分。像 Google 的 Material Design 這樣的框架把動畫作為其設計語言的重要組成部分，並認為它們對於創造富有表現力和易於理解的使用者體驗至關重要。鑑於它們的重要性的提高，最近推出了一個更強大的 JavaScript 動畫 API，這個就是 Web Animations API（WAAPI）。
正如 CSS-Tricks 所說，WAAPI 提供了比 CSS 動畫更好的開發人員體驗，你可以輕鬆地記錄和操作 JS 或 CSS 中定義的動畫狀態。目前瀏覽器支援主要限於 Chrome 和 Firefox，但有一個官方的 polyfill 可以滿足你的需求。
效能一直是 Web 動畫的一個問題，Animation Worklet 解決了這個問題。這個新的 API 允許複雜的動畫並行執行 —— 這意味著更高的幀速率動畫不受主執行緒卡頓的影響。Animation Worklet 遵循與 Web Animations API 相同的介面，但在 Worklet 執行上下文中。
它將在 Chrome 71（截至撰寫本文時的下一個版本）釋出，而其他瀏覽器可能會在明年某個時候釋出。如果想今天就試試，可以在 GitHub 上找到官方的 polyfill 和示例倉庫。
安全
Spectre 定時攻擊並不是今年唯一的網路安全恐慌。npm 固有的脆弱性在過去已經寫了很多，上個月我們得到了一個告警提醒。這不是 npm 本身的安全漏洞，而是一個名為 event-stream 的包，被許多流行軟體包使用。npm 允許包作者將所有權轉讓給任何其他成員，黑客說服所有者將其轉讓給他們。然後，黑客釋出了一個新版本，它依賴於他們建立的名為 flatmap-stream 的軟體包，其程式碼可以竊取比特幣錢包，如果該惡意軟體和 copay-dash 一起安裝，就會竊取使用者的比特幣錢包。
考慮到 npm 的執行方式，社群成員傾向於安裝看似有用的隨機 npm 包，這種攻擊只會變得更加普遍。社群對包所有者非常信任，現在信任受到了極大的質疑。npm 使用者應該知道他們正在安裝的每個軟體包（包括依賴項的依賴關係），使用鎖定檔案來鎖定版本並註冊 Github 提供的安全警報。
Npm 意識到社群的安全問題，他們在過去的一年裡已經採取措施去改進它。你現在可以使用雙因素身份驗證來保護你的 npm 帳戶，並且 npm v6 現在包含了安全稽核命令。
監控
Reporting API 是一種新標準，旨在通過在發生問題時發出警報，使開發人員更容易發現應用程式的問題。如果你在過去幾年中使用過 Chrome DevTools 控制檯，你可能已經看到了 [intervention] 警告訊息，用來提醒使用者使用了過時的 API 或執行了可能不安全的操作。這些訊息僅限於客戶端，但現在你可以使用新的 ReportingObserver 將其報告給分析工具。
有兩種報告：
而像 LogRocket 這樣的工具可以讓開發人員深入瞭解應用程式中的錯誤。到目前為止，第三方工具還沒有任何可靠的方法來記錄這些警告。這意味著問題要麼被忽視，要麼表現為難以除錯的錯誤訊息。Chrome 目前支援了 ReportingObserver API，其他瀏覽器很快就會支援它。
CSS
雖然 JavaScript 得到了所有人的關注，但幾個有趣的 CSS 新功能在今年登陸了瀏覽器。
很多人不知道，其實並沒有統一的類似於 ECMAScript 的 CSS3 規範。最後一個官方統一標準是 CSS2.1，而 CSS3 適用於在其之後釋出的內容。與 CSS2 不同的是，CSS3 的每個部分都單獨標準化為 “CSS 模組”。 MDN 對每個模組標準及其狀態有一個很好的概述。
截至 2018 年，現在所有主流瀏覽器都完全支援一些較新的功能（這是 2018 年，IE 不是主流瀏覽器）。這包括 flexbox、自定義屬性（變數）和網格佈局。
雖然過去一直在討論如何向 CSS 新增對巢狀規則的支援（就像 LESS 和 SASS 那樣），但這些提案被擱置了。在 7 月，W3C 的 CSS 工作組決定再次審視該提案，但目前還不清楚它是否是一個優先事項。
Node.js
Node 繼續在遵循 ECMAScript 標準方面取得良好進展，截至 12 月，它們支援了所有 ES2018 標準。但另一方面，他們採用 ECMAScript 模組系統的速度很慢，因此缺少一項與瀏覽器比肩的關鍵功能，瀏覽器已經支援 ES 模組一年多了。Node 實際上在 v11.4.0 版本標誌後面新增了一項實驗支援，但是這需要檔案使用新的 .mjs 字尾，這使得他們開始擔憂：使用者的接受速度可能會十分緩慢，以及其對 Node 的豐富包生態系統的影響。
如果你希望快速開始，並且不想使用實驗性內建支援，可以嘗試使用被 Lodash 的建立者稱為 esm 的一個有趣的專案，它為 Node ES 模組支援提供了比官方解決方案更好的互操作性和效能。
框架和工具
React
React 今年釋出了兩個值得注意的版本。React 16.3 附帶了一組新的生命週期方法和一個新的官方 Context API。React 16.6 新增了一個名為 “Suspense” 的新功能，它使 React 能夠在元件等待如資料獲取或程式碼分割等任務完成時暫停渲染。
今年最受關注的 React 話題是引入了 React Hooks。該提案為了讓編寫更小的元件更簡單，並且不會犧牲迄今為止僅限於類元件的有用功能。React 將附帶兩個內建鉤子，State Hook（允許函式式元件使用狀態）和 Effect Hook（可以讓你在函式式元件中執行副作用）。雖然沒有計劃從 React 中刪除類，但 React 團隊顯然希望 Hooks 成為 React 未來的核心。提案宣佈之後，社群有了積極的反應（有些人可能會說過度誇大了）。如果你有興趣瞭解更多資訊，請檢視 Dan Abramov 的博文裡面的全面概述。
明年，React 計劃釋出一項名為 Concurrent mode（以前稱為 “async mode” 或 “async rendering”）的新功能。這將使 React 在不阻塞主執行緒的情況下渲染大型元件樹。對於具有深度元件樹的大型應用程式，效能的節省可能非常顯著。目前還不清楚該 API 究竟是什麼樣子，但 React 團隊的目標是很快完成它並在明年某個時候釋出。如果你對採用此功能感興趣，請通過採用 React 16.3 中釋出的新生命週期方法確保你的程式碼能夠相容該功能。
React 流行度繼續增長，根據 JavaScript 2018 趨勢報告顯示，64％ 的受訪者選擇使用 React 並將再次使用它（比去年增加了 7.1％），相比之下 Vue 為 28％（增長了 9.2％），Angular 為 23%（增長了 5.1％）。
Webpack
Webpack 4 於 2 月釋出，帶來了巨大的效能改進，內建生產和開發模式，做了如程式碼分割和壓縮的易於使用的優化，實驗性的 WebAssembly 支援和 ECMAScript 模組支援。Webpack 現在比以前的版本更容易使用，以前如程式碼分割和程式碼優化等複雜的功能，現在設定起來非常簡單。結合使用 Typescript 或 Babel，webpack 仍然是 Web 開發人員的基礎工具，競爭對手似乎不太可能在不久的將來出現並取而代之。
Babel
Babel 7 於今年 8 月釋出，這是近三年來的第一次重大發布。主要更改包括更快的構建時間，新的包名稱空間以及各種“階段”和按照年度命名的 ECMASCript 預設包的棄用，以支援 preset-env，它通過自動包含你支援的瀏覽器所需的外掛，極大地簡化了配置 Babel 的過程。此版本還新增了自動 polyfilling，無需匯入整個 Babel polyfill（體積相當大）或顯式匯入所需的 polyfill（這可能非常耗時且容易出錯）。
Babel 現在也支援 Typescript 語法，使開發人員更容易將 Babel 和 Typescript 一起使用。Babel 7.1 還增加了對新的裝飾器提案的支援，該提議與社群廣泛採用的過時提案不相容，但與瀏覽器支援的內容相匹配。值得慶幸的是，Babel 團隊釋出了一個相容性軟體包，可以使升級更容易。
Electron
Electron 仍然是最常用的桌面 JavaScript 應用程式打包方式，儘管這是否是一件好事還是有爭議的。現在一些最流行的桌面應用程式使用了 Electron，可以使跨平臺開發應用程式更加簡單，從而降低開發成本。
一個常見的抱怨是，使用 Electron 的應用程式會使用太多記憶體，因為每個應用程式都打包整個 Chrome 例項（這會非常佔用記憶體）。Carlo 是來自 Google 的 Electron 替代品，它使用本地安裝的 Chrome 版本（需要在本地安裝），從而減少了記憶體消耗大的問題。Electron 本身在提高效能方面沒有取得多大進展，近期的更新主要集中在更新 Chrome 依賴項和小的 API 改動上面。
Typescript
在去年，Typescript 的受歡迎程度大大提高，成為了JavaScript 統治地位的 ES6 的主要挑戰者。自微軟每月釋出新版本以來，開發在過去一年中取得了相當快的進展。Typescript 團隊非常關注開發人員的體驗，包括語言本身和圍繞它的編輯器工具。
最近的版本增加了更多開發人員友好的錯誤格式和強大的重構功能，如自動匯入更新和匯入組織等。與此同時，TypeScript 繼續在提升型別系統上發力，如近期的條件型別和未知型別兩個新功能。
JavaScript 2018 趨勢報告指出，近一半的受訪者使用 TypeScript，和過去兩年相比具有強勁的上升趨勢。相比之下，它的主要競爭對手 Flow 已經停滯不前，大多數開發者表示他們不喜歡 Flow 缺乏工具，並且流行勢頭降低。Typescript 受到讚賞，因為開發人員可以通過使用強大的編輯器輕鬆編寫健壯且優雅的程式碼。開發者注意到了，TypeScript 的發起者微軟似乎更願意支援它，而 Facebook 對 Flow 的支援就差了一截。
題外話：LogRocket，一個用於 web 應用程式的DVR
LogRocket 是一個前端日誌記錄工具，可讓你像在自己的瀏覽器中一樣重現問題。LogRocket 不是猜測錯誤發生的原因，也不是要求使用者提供螢幕截圖和日誌轉儲，而是讓你重播會話以快速瞭解出現了什麼問題。它適用於任何應用程式，與框架無關，並且具有從 Redux、Vuex 和 @ngrx / store 記錄上下文的日誌外掛。
除了記錄 Redux 操作和狀態之外，LogRocket 還會記錄控制檯日誌、JavaScript 錯誤、堆疊跟蹤、帶有 header 和 body 的網路請求/響應、瀏覽器後設資料和自定義日誌。它還使用 DOM 來記錄頁面上的 HTML 和 CSS，能夠重新建立即使是最複雜的單頁應用程式的畫素級完美視訊。
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。