作者：騰訊 IMWeb 前端團隊

2021 年大前端領域沒有出現(xiàn)革命性的明星項目，但在各個細分的技術領域都有一定的拓展與深耕，有很多新技術或者新特性有望在 2022 年迎來爆發(fā)。在互聯(lián)網 “寒冬” 的當下，前端技術人員唯有修煉好內功，不斷壯大自身，才能更好地迎接春天的 “東風”。那前端技術人員應該修煉哪一塊 “肌肉” 呢，或許我們可以在《2021 年 JavaScript 明星項目》找到一些答案：

• zx 工具包僅用了 7 個月就榮登全年 Star 增長最快的項目，這側面表明了前端開發(fā)在全棧的持續(xù)滲透和影響力。
• 在前端框架上面，龍頭 React 和 Vue 還是穩(wěn)步發(fā)展，持續(xù)創(chuàng)新。而黑馬 Svelte 在今年崛起，一舉超越 Angular 占據(jù)第三位，并對頭名虎視眈眈。那么 Svelte 能否破局？
• 在 Node.js 框架中，React 的 “元框架” Next.js 一騎絕塵。而新秀 Remix 僅僅 2 個月就沖到了第四，值得關注。
• 在構建工具上面，對原生 ES 模塊的接納仍在繼續(xù)，vite 勢頭難擋，另一方面，出于對性能的考慮，越來越多的前端工具開始用其他語言 (Rust、Go) 來構建。
• 在桌面端，大火的 Tauri 打破了 Electron 的統(tǒng)治，基于 Rust (可替換)，Tauri 對比 Electron 有更小的包大小和內存占用，未來可期。

接下來，主要盤點下 2021 年前端行業(yè)發(fā)生了哪些重要的事情，同時分享下騰訊 IMWeb 團隊在過去一年中都做了哪些工作。

總結 2021 年度趨勢

1、 TypeScript 穩(wěn)健增長

從 Github 的語言使用數(shù)據(jù) （Top languages over the years）來看，2021 TypeScript 依然穩(wěn)居第四。

從最新的 2020 JS 問卷調查數(shù)據(jù)看，TypeScript 使用率在同類工具競爭中依舊排名第一（ State of JS survey）。

從 Stack Overflow Developer Survey 2021 來看，TypeScript 受大家喜愛程度依舊在提升，估計在 2022 年還會保持增長。

回顧

回顧 2021，官方的 Roadmap 闡明了 TypeScript 的目標是繼續(xù)完善其類型系統(tǒng)、實現(xiàn)強大的工具提高生產力、提高使用體驗、提高社區(qū)參與程度、改進基礎設施和工程化系統(tǒng)。提出目標后，這一年 TypeScript 團隊還是非常給力的發(fā)了 4 個版本，目前最新版本 4.5，其中許多新特性確實使用起來更香了，比如：

• 更好的元組類型支持，允許任意位置的剩余類型以及可選類型。
• 更好的模板字符串字面量類型支持。
• 更智能的條件分支域的類型推斷。
• 索引類型支持 Symbol 和模板字符串模式。
• Awaited 類型和 Promise 類型改進。

除了特性，它還完善了許多使用體驗，比如：

• 性能優(yōu)化如更快的類型生成、增量編譯和 Sourcemap 生成。
• 更智能的 IDE 補全。
• 非 Javascript 源文件定位。

另外， TypeScript 新官網在 8 月上線了，全新的文檔查閱起來也更加方便。

目前 TypeScript 已經是 IMWeb 團隊的標配。無論是 Web 前端、Node.js 項目還是公共模塊，從腳手架模板就默認支持 TypeScript，其中公共模塊體系不僅僅使用 TypeScript 編寫代碼和類型檢查，同時利用 ESLint 實現(xiàn) TS 語言標準 AST 的特定校驗來實現(xiàn)公共模塊規(guī)范，還結合 TypeDoc 生成使用文檔等等。

展望

TypeScript 在未來將提供更多激動人心的特性，例如：

• 扁平化聲明文件（Flattening declarations），只輸出一份總的 d.ts 文件，而不是一個模塊一個 d.ts 文件。
• 環(huán)境裝飾器（Ambient decorators），用來聲明一些環(huán)境信息，例如 API 是否是 deprecated。不影響輸出的運行時代碼，只在 d.ts 聲明文件中體現(xiàn)。
• 條件編譯（Conditional compilation），有點類似 C 中的 #if 宏定義，可以在編譯前預處理代碼并保留符合條件的代碼分支。
• 函數(shù)表達式以及箭頭函數(shù)的裝飾器（Decorators for function expressions/arrow functions），目前 TypeScript 中裝飾器只能用于 class 中，未來將可能支持類外的函數(shù)表達式以及箭頭函數(shù)使用裝飾器。

正如其 Roadmap 所說，TypeScript 正在朝正確的方向前進，提高生產力還有很多的類型特性、性能優(yōu)化、體驗優(yōu)化、配套工具可以做，正努力成為 JS 語言的標準類型系統(tǒng)。隨著 TypeScript 的日益發(fā)展和完善，未來，TypeScript 是否能得到瀏覽器和 Node.js 原生支持呢？我們一起期待吧。

2、React 一馬當先且持續(xù)創(chuàng)新

React 18 在 2021 年下半年完成了 Alpha、Beta 和 Release Candidate 版本的發(fā)布，將于 2022 年初發(fā)布正式版本。

當 React 18 發(fā)布時，它將包含開箱即用的改進（如 Automatic batching)，全新的 API（如 startTransition）以及內置支持了 React.lazy 的全新 SSR 架構。這些功能之所以能夠實現(xiàn)，要歸功于在 React 18 中新加入的可選的 “并發(fā)渲染（concurrent rendering）” 機制，它為 React 解鎖了非常多新的可能性，來幫助你提高你應用程序的實際與感知性能。

React 18 采用循序漸進的策略，由于 React 18 中的并發(fā)性是可選功能，所以并不會立刻對組件行為帶來任何明顯的破壞性變化。你幾乎不需要對應用程序中的代碼進行任何改動就可以直接升級到 React 18，且可以根據(jù)自己的節(jié)奏和需要來嘗試新特性。總的來說，React 18 帶來了以下 3 個方面的更新：

? Automatic batching

? SSR for Suspense

? New APIs for app and library developers

? Automatic batching

React 18 通過默認執(zhí)行更多 batching (批處理) 來增加開箱即用的性能改進，無需在應用程序或庫代碼中手動批處理更新。batching 是指，React 可以將回調函數(shù)中多個 setState 事件合并為一次渲染。

React 17 只在事件回調中 batching，React 18 則會對任何來源的 setState 做盡可能多的 batching， 即使在 promise、timeout 或者 event 回調中調用多次 setState，也都會合并為一次渲染。將 ReactDOM.render 替換為 ReactDOM.createRoot 調用方式，即可開啟這些新特性。

● SSR for Suspense

完整名稱是：Streaming SSR with selective hydration。

即像水流一樣，打造一個從服務端到客戶端持續(xù)不斷的渲染管線，而不是 renderToString 那樣一次性渲染機制。selective hydration 表示選擇性水合，水合指的是后端內容打到前端后，JS 需要將事件綁定其上，才能響應用戶交互或者 DOM 更新行為，而在 React 18 之前，這個操作必須是整體性的，而水合過程可能比較慢，會引起全局的卡頓，所以選擇性水合可以按需優(yōu)先進行水合。

● New APIs for app and library developers

Concurrent APIs：

Concurrent Rendering 相關的變動是 React 18 的主要變動之一，簡而言之，這個能力會讓 React 應用保持更好的響應性。這是一種可中斷渲染的設計架構。什么時候中斷渲染呢？當一個更高優(yōu)先級渲染到來時，通過放棄當前的渲染，立即執(zhí)行更高優(yōu)先級的渲染，換來視覺上更快的響應速度。

• useTransition：允許組件在切換到下一個界面之前等待內容加載，從而避免不必要的加載狀態(tài)。
• startTransition：被 startTransition 回調包裹的 setState 觸發(fā)的渲染 被標記為不緊急的渲染，這些渲染可能被其他緊急渲染所搶占。
• useDeferredValue：返回一個延遲響應的值，例如一個選擇輸入框過濾列表的場景，我們可以針對列表使用 useDeferredValue 傳入選擇器對應的值。

新的 startTransition 與 useDeferredValue API，本質上都是允許你將 UI 的一部分標記為較低的更新優(yōu)先級。

其他 APIs：

• useSyncExternalStore：useSyncExternalStore 將替代 useMutableSource 用于訂閱外部源，解決 Concurrent Rendering 可能導致的數(shù)據(jù)不一致的問題，也是庫作者可能需要，一般開發(fā)者不太能用到。
• useId：useId 用于在客戶端與服務端之間產生唯一 ID ，避免 SSR hydrate 時元素不匹配。
• useInsertionEffect：用于插入全局 DOM 節(jié)點。

React 18 將在明年與新的 React Native 架構（可用 React 18 特性）一起發(fā)布。

3、Svelte 前端框架戰(zhàn)局中的黑馬

前端領域風起云涌，框架層出不窮，前端三大馬車 React、Vue、Angular 始終穩(wěn)居前三甲。同時我們也注意到在眾多前端框架中，由 Rich Harris (Ractive, Rollup 和 Bubble 的作者) 開發(fā)的 Svelte 有望成為一批黑馬，在前端框架中脫穎而出。

在《Stack Overflow 于 2021 年準備的最新調查》中，71.47% 的受訪者將 Svelte 選為最受歡迎的框架，領先于 React.js 的 69.28% 和 Vue 的 64.41%。而在 JS 現(xiàn)狀 2020 調查 中，Svelte 在用戶滿意度 89%、興趣度 66% 均取得了第一的成績表現(xiàn)。Svelte 從一誕生，就用來對標 React/Vue 等框架，我們也看到了關于 Svelte 與 React 的爭論，看到了 19 年尤大回復的《如何看待 Svelte 這個前端框架》以及 21 年 vue-Svelte-size-analysis 評測，足見 Svelte 的發(fā)展態(tài)勢。

前端戰(zhàn)局中的黑馬

我們調查發(fā)現(xiàn)，開發(fā)者喜愛 Svelte，主要源于以下幾點：

1、更高的開發(fā)效率。Svelte 有著極其簡潔的語法，交互式教程讓其有較低的學習曲線和上手成本，熟悉 vue 語法的基本上很快能夠上手。

2、更小的體積。Svelte 的核心思想在于通過靜態(tài)編譯減少框架運行時的代碼量，這在小型應用中，優(yōu)勢相當明顯，React 的壓縮版本大小為 42.2KB，Svelte 的壓縮版本大小為 1.6KB。但是在中大型應用中，這個優(yōu)勢會被慢慢縮小，甚至成為劣勢。

3、更高的性能。Svelte 沒有采用現(xiàn)在普遍使用的 Virtual Dom，而是另辟蹊徑采用 Template 語法，讓編譯器在編譯階段就記錄了哪些數(shù)據(jù)需要更新。這讓 Svelte 性能不僅勝過 React，還勝過 Angular 和 Vue。

4、更優(yōu)的 Web Components 分發(fā)。Svelte 直接編譯成 JS，生成瀏覽器能夠識別的 Web Components 組件，這讓基于 Svelte 開發(fā)的組件能夠用于其它框架，譬如 React/Vue/Angular 等。

時光飛逝，Svelte 的發(fā)展速度可能也超乎我們的想象。被詬病不支持 TypeScript 的前端框架沒有未來的 Svelte 在 2021 年也支持了 TypeScript，UI 庫 Svelte Material UI 也在逐步迭代中，開發(fā)者社區(qū)也加入了越來越多的小伙伴，豐富了 Svelte 在單元測試、Web Components、SSR 等方面的實踐。

回顧 2021 年，Svelte 最重要的莫過于下面兩件事：

1、2021 年 11 月 20 日舉辦了秋季峰會。峰會 Rich Harris 給我們講述了 Svelte 的歷史，并宣布他將入職 Vercel，之后全職維護 Svelte。峰會上也邀請到了社區(qū)眾多的開發(fā)者，分享 Svelte 的一些實踐，讓我們看到 Svelte 更多的可能性。

2、SvelteKit 正式發(fā)布 beta 版。SvelteKit 是基于 Svelte 開發(fā)的 web 應用框架，類似于基于 Vue.js 開發(fā)的 Nuxt.js 框架。它繼承了服務端渲染 SSR，路由，支持 TypeScript，支持 less/sass，支持 Vite 打包等特性。既能高效開發(fā)，又高性能。盡管目前 SvelteKit 目前還有些 bug 仍需要解決，部分缺失的功能亟待完善。但仍不妨礙項目敢在生產環(huán)境去使用它。

靜待花開的攪局者

雖然我們看到 Svelte 深受開發(fā)者的喜歡，但是到目前為止，仍然很難看到有大型應用在使用 Svelte，其性能優(yōu)勢、體積優(yōu)勢等并沒有在大型應用中得到驗證。由于 React/Vue/Angular 先入為主，尤其是在大公司，已經有非常完備成體系的配套方案，成熟的體系基本上很難去改動，后起之秀也很難有如 React 等框架活躍的社區(qū)，Svelte 要走的路還是很長。但是我們觀察到，包括阿里、字節(jié)、騰訊等大公司也都在新業(yè)務中嘗試使用 Svelte 開發(fā)，在中小型應用、h5 應用、Web Components 等方面確實有它的優(yōu)勢所在，也值得嘗試。盡管 Svelte 有很多優(yōu)勢，但想以一己之力挑戰(zhàn) React/Vue/Angular 的江湖地位，目前來看還是需要靜待標桿大型應用，靜待各大大公司推出基于 Svelte 開發(fā)的 UI 庫，或許 Svelte 大放異彩的時機就會到來。

4、桌面端 – 前端開發(fā)的下一個戰(zhàn)場

持續(xù)擴大桌面應用領域影響

自 2014 年 Github 推出 Electron 開源框架開始，前端跳出 Web 客戶端局限，開發(fā)桌面應用的能力成為了可能，近年來，依托 Electron、React Native、Flutter 等應用框架，前端跨端開發(fā)桌面應用的概念持續(xù)升溫。盡管這些方案和傳統(tǒng)的 QT、Xaramrin 等技術棧相比，性能未必最優(yōu)，但它意味著一些極具性價比的可選方案出現(xiàn)，大大降低了開發(fā)桌面應用的門檻。

2021 年，前端 Electron、React Native Desktop 等應用框架的更新迭代都趨于穩(wěn)定，雖然沒有了一些突破性的亮點功能出現(xiàn)，但各個框架都針對性能、應用場景等痛點問題在持續(xù)進行深入的優(yōu)化，而近年概念火熱的 Flutter 也將它的桌面版在 21 年納入了 Beta 階段，異軍突起的 Tauri 以其優(yōu)異的性能和包大小受到了關注，潛力不容小覷?？傮w而言，在桌面應用開發(fā)領域，前端技術的影響力在與日俱增，前端可以參與的內容比重也在不斷增加。

Electron

Electron 是 GitHub 開發(fā)的一個開源框架。它通過使用 Node.js（作為后端）和 Chromium 的渲染引擎（作為前端）完成跨平臺的桌面 GUI 應用程序的開發(fā)。已有大量知名桌面應用采用 Electron 進行開發(fā)，如 slack、VSCode 等。Electron 的所需開發(fā)能力與前端開發(fā)能力技術棧有著較大的重合，因此對于前端開發(fā)同學來說，使用 Electron 進行桌面開發(fā)的上手門檻較低，同時 Electron 作為一個深耕迭代 8 年的項目，應用生態(tài)鏈豐富，進一步減少了上手成本。

使用 Electron 進行桌面應用開發(fā)，對于前端自身能力提升也有賦能，一方面擴展了技術廣度，可以將前端的業(yè)務能力范疇由單一的 Web 端頁面擴展到 PC 應用開發(fā)，一些目前 Electron 暫時不支持的能力，還可通過 C 編寫 Node 組件來擴展支持；另一方面很多前端側的限制被打破，比如一些傳統(tǒng)的 Web 安全限制，系統(tǒng)底層接口的調用，能夠做到開發(fā)能力賦能。

當然，Electron 也并不是全無缺陷的，一些常受詬病的缺點有：

• 打包體積過大，由于捆綁了 Chromium 內核等大量依賴，導致 Electron 的打包體積普遍在 100M ，這一點我們可以使用 asar 壓縮、動態(tài)鏈接庫等方式進行優(yōu)化。
• 內存占用高，同樣的由于捆綁了 Chromium 內核，Electron 的內存占用普遍也較高。
• UI 層視覺渲染效率低，這一點也可以通過優(yōu)化手段，如多進程處理任務、甚至利用視覺假象來提升用戶體驗。

雖然 Electron 有著一些已知的問題，但完善的生態(tài)鏈、與前端技術的高度重合，目前仍然是快速開發(fā)桌面應用的推薦方案，對于性能問題我們也較容易通過一些常見的優(yōu)化手段來進行解決，達到 80 分的程度。2021 年，Electron 依然保持著 8 周一個 major 版本的穩(wěn)定更新頻率，推出了 V12 到 V15 的多個大版本，更新的內容主要集中在 API 的刪改、系統(tǒng)特性的適配、Chromium 內核等依賴的版本更新等細節(jié)方面。

React Native Desktop

React Native 是 Facebook 技術團隊于 2015 年 4 月在早先的 React 前端框架基礎上開源的一套移動跨平臺開發(fā)框架。對于桌面應用的構建，目前 RN 團隊暫時沒有推出官方的桌面端版本，主要依托社區(qū)項目進行持續(xù)發(fā)展的能力建設。在這之中，微軟開發(fā)的 React Native For Windows macOS 技術方案是經驗積累最多，也是開發(fā)迭代最為穩(wěn)定的方案，自 15 年底項目發(fā)布以來，已經經過了 6 年的穩(wěn)定迭代。2021 年 RN 團隊推出了 0.64-0.66 三個重要版本，而微軟在 React Native For Windows 的迭代中，也時刻保證對 RN 主版本的更新，同時也支持了大量 Windows 相關的特性。如果你構建的桌面應用主要目標用戶在 Windows 平臺，那么使用 React Native For Windows 不失為一個好的選擇。

值得一提的是，2021 年 RN 技術團隊除了在推出的重要版本中提供對新的 Android 12 與 iOS 15 系統(tǒng)的支持外，也著重提到了與微軟團隊在桌面應用構建技術上的共建，RN 團隊表示，將通過引入 Facebook 的 Messenger 團隊共建，來為桌面應用提供一些「獨有的」技術能力，以此提升 React Native 桌面版的用戶體驗，對此，我們也將拭目以待。

Flutter Desktop

Flutter 是由谷歌推出的移動 UI 混合開發(fā)框架，它實現(xiàn)了一整套自底而上的基礎庫，用戶可以在 iOS 和 Android 構建高質量的原生用戶界面。

目前 Flutter 為了支持在桌面?zhèn)鹊拈_發(fā)能力，采用的是把代碼轉成 Web 的跨端渲染方案。但 Flutter to Web 性能還存在著大量提升的空間，雖然這一年內業(yè)內有不少優(yōu)化方案，但想要性能有明顯提升，多少都會通過魔改 Flutter 源碼的方式來實現(xiàn)，這些優(yōu)化手段在長期的 Flutter 版本迭代過程中，會有較大的優(yōu)化成本。即使這樣，優(yōu)化過后的 Flutter to Web 性能，和傳統(tǒng)的 Web 項目相比，也略有不足。所以在不考慮兼容性的前提下，采用 to Web 方案的開發(fā)盡量使用 Canvaskit Render 模式，該模式是基于 Skia 的 WebAssembly 方案，會有更好的渲染性能，但加載性能方面還需持續(xù)優(yōu)化。

可能是為了徹底解決桌面端的性能問題，2021 年中，F(xiàn)lutter Desktop 側推出了 Windows Native 方案，但它目前僅支持 64 位系統(tǒng)，這使得它無法支持 Win7 等較低 32 位系統(tǒng)的 Windows 版本，會大大增加了開發(fā)者的兼容成本。不過 2022 年 2 月，F(xiàn)lutter Desktop 正式推出了穩(wěn)定版，適配了許多常用插件以包含對 Windows 的支持，包括 camera，file_picker 和 shared_preferences。更重要的是，社區(qū)已經添加了各種其他 package 對 Windows 的支持，涵蓋了從 Windows 任務欄集成到串行端口訪問的全部內容。同時許多 Microsoft 的團隊也積極配合，為正式版的發(fā)布做出了很大貢獻。2022 年，F(xiàn)lutter Desktop 值得嘗試一下。

Tauri

最近搭上 Rust 的東風的 Tauri 受到非常多的關注，對標 Electron，主要有以下 4 點優(yōu)勢：

• 包體積大小更小
• 運行時內存占用更小
• 安全擺在第一位
• 真正的開源

但是理性思考，對于前端開發(fā)來說，有三個致命的缺點：

• Tauri 使用系統(tǒng) webview，會有兼容性問題，這也是 Electron 重點解決的問題
• 拋棄了 nodejs，生態(tài)圈目前來說還是很難比得上 Electron 的
• 底層開發(fā)要用 Rust，有一定的上手成本

當然 Tauri 現(xiàn)在還不是非常成熟，但是隨著 Rust 的生態(tài)起來，瀏覽器兼容性漸小之后，勝負猶未可知。

6、Rust-是時候掌握一門新語言了

Rust 是 JS 基礎設施的未來

隨著前端生態(tài)工具的逐漸完善，大家除了探索前端的新領域之外，同時還在思考如何提高工具的性能，眾所周知，JavaScript 的性能一直是被大家所詬病的點，但是前端的基礎設施卻是十分要求性能的，比如構建等，所以大家開始考慮是否能夠用別的語言來編寫前端工具，于是 Rust 吸引了大家的眼球，Rust 語言自誕生以來，就以它的安全性、性能、現(xiàn)代化的語法吸引了大批的開發(fā)者，在過去六年的 stackoverflow 最受喜愛的編程和語言中連續(xù)獲得榜首的位置，并且已經有眾多領域都出現(xiàn)了 Rust 重寫的項目，Linux 項目也表示正在使用 Rust 重寫一部分功能，可以說 Rust 進入前端領域也是一種必然的趨勢。Lee Robinson 在 2021 年寫的一篇文章《Rust Is The Future of JavaScript Infrastucture》（《Rust 是 JS 基礎設施的未來》）列舉了眾多 Rust 編寫的前端工具項目，并表示 Rust 將會持續(xù)加大影響 Javascript 的生態(tài)圈，這篇文章也是被眾多公眾號轉了個遍，引發(fā)大家的熱烈討論。

Rust 工具融入前端生態(tài)

在前端構建領域，2021 年出現(xiàn)了一個十分突出的項目 —— swc，它是由 Rust 編寫的構建工具，可以用來編譯、壓縮、打包，目前它已經被一些知名項目使用，比如 Next.js、Parcel、Deno 等，Next.js 12 直接使用了 swc 替代 babel，并在他們的官網博客表示說使用了 swc 之后，熱更新速度提升到了原來的三倍，構建速度提升到了 5 倍，由此可見，Rust 性能的強大。

除了構建方面，在前端的其他領域也是有著 Rust 的身影，比如 Deno 的運行時引擎也是用的 Rust 編寫的 V8 引擎；前端的下一代工具全家桶 Rome 宣布使用 Rust 重寫；Node.js 可以通過 napi-rs 來調用 Rust 模塊，實現(xiàn)高性能擴展；使用 Rust 編寫的 dprint 規(guī)范代碼器，要比 Prettier 快 30 倍；Rust 也可以編譯成 WASM，并且出現(xiàn)了像 yew、percy 這樣的 WASM 前端框架。

可以預見的是，Rust 工具將會更加深度地融入前端生態(tài)，說不定會引發(fā)前端生態(tài)的又一次更新?lián)Q代。

前端人是時候學習一門新語言

相信有不少人看到過這樣一個推特截圖，Redux 作者 Dan Abramov 在某個提問 “未來三年最值得學習的語言是什么” 下回答了 “Rust”，這或許是對前端人員的一個啟發(fā)，我們也是時候學習一門新語言來讓前端生態(tài)圈再次煥發(fā)活力了，可是不少人會被 Rust 陡峭的學習路線給勸退，但其實 Rust 在不少地方是跟前端開發(fā)有著相似的地方的，要想入門的話也并不是那么陡峭。

比如，在工具鏈上，Rust 的 rustup 就相當于 nvm，可以切換運行工具 cargo（Rust 版的 npm）的版本，但它也比 nvm 強大，在安裝 rustup 的同時，還會安裝 clippy（Rust 版的 eslint）、rustfmt（Rust 版的 prettier），用 Rust 配套工具新建的項目就已經帶有代碼格式化、分析配套的工具。

再來看看 cargo 與 npm 的相似之處，兩個工具在很多命令上都有著相似的地方，并且 npm 一些需要自己在項目配置的命令在 cargo 這是不需要配置的，甚至 cargo 是自帶了 monorepo 的管理，可以直接配置多 package 的項目，與其說 cargo 跟 npm 對應，倒不如說 cargo 更像是 npm 與 yarn 的結合，這也是 Rust 團隊借鑒參考現(xiàn)代化語言工具鏈的成果。

在語法上 Rust 也是極具現(xiàn)代化語言的特點，借鑒了函數(shù)式編程、結構化語言的特點，并且在它們的基礎上也創(chuàng)造了許多更為先進的語法。在函數(shù)式編程的地方，也有著不少 JavaScript 的身影，比如 JS 的箭頭函數(shù)對應了 Rust 的閉合函數(shù)；Rust 的數(shù)組同樣也有著 map、reduce、filter 等方法；Rust 的函數(shù)也可以賦值給一個變量。

如果在以前說前端可以去學習的第二語言是 C ，那么現(xiàn)在或許就是 Rust 了，它有著比 C 更現(xiàn)代化的依賴管理、語法、工具鏈，讓你不至于在一開始就被勸退，還能讓你在前端領域更具競爭力。

6、低代碼將持續(xù)成為熱點話題

距我們在 2020 技術趨勢中談及 “低代碼” 又過去了一年，從 2020 年 19 億到 2021 年 28.5 億的市場規(guī)模，無疑表明該領域依舊火熱，依舊在快速發(fā)展中。如果說 2020 年讓我們收獲了對低代碼領域持續(xù)升溫的預期，那么 2021 年則讓我們看到了更多關于低代碼領域未來發(fā)展的趨勢。

一方面，我們看到騰訊微搭、阿里宜搭等企業(yè)級低代碼平臺在行業(yè)內開始發(fā)力，公司內也有無極等專注管理臺搭建的平臺逐步成熟。大量平臺型產品仍在差異化高速發(fā)展，仍是主流的發(fā)展思路。在 IMWeb 團隊內，從 19 年開始的運營低碼平臺 Vision，到 20 年的管理臺低碼框架 Hulk，我們一直在通過垂直類低碼平臺加速業(yè)務研發(fā)。2021 年，我們進一步在服務端場景進行了嘗試，打磨出了專注接口搭建的 HulkData 平臺。

HulkData 通過 Web 可視化組件搭建流水線，基于數(shù)據(jù)庫或已有 API，配合少量代碼生成全新的 API 接口。HulkData 借鑒 BPMN 2.0 協(xié)議使用圖形來表達業(yè)務流程 ，支持多業(yè)務，多數(shù)據(jù)資源，低代碼、插件機制、流程編排、請求和響應參數(shù)修改。Serverless 日漸成熟，Serverless 的無運維特性對 HulkData 而言是一個非常良好的契機，在 HulkData 上創(chuàng)建的接口會以 SCF 的方式部署到騰訊云，不需要再關注服務器運維。使用 HulkData 服務端接口編排可快速實現(xiàn)業(yè)務邏輯，敏捷接付業(yè)務應用，比傳統(tǒng)開發(fā)模式交付速度提升 80%。目前內部三大業(yè)務接入使用共 400 接口在正常運行。

另一方面，值得思考的是，在高速發(fā)展的差異化、場景化的平臺產品之間，是否存在某些共性？畢竟不管針對什么場景，從零建設一個低碼平臺的成本絕不低，此類的資源浪費在大廠里尤為突出。

20 年底 IMWeb 團隊內啟動的 Gems 低代碼引擎項目，其實就是對這個問題的探索。低代碼引擎的核心目標，是提供一套基礎標準、設施，幫助上層平臺更有效地建設。而其思路的關鍵，在于引擎模型及能力的完備性、以及針對不同場景下的可擴展性。Gems 作為低代碼引擎，在 21 年里不斷完善自身的基礎能力與設計，提供了全面板插件化、核心編輯對象 API 等能力。除了平穩(wěn)支撐團隊內的運營與管理臺低碼平臺，也逐步邁出到團隊之外，幫助到公司內多個團隊在自身業(yè)務場景低碼平臺的高效建設。有關 Gems 的更多內容可以關注我們團隊在 QCon 的相關分享。

同時，我們也看到在今年底的 GMTC 大會上，阿里已經對外宣傳了集團的低代碼引擎，從分享內容看已經支撐了 60 多個低代碼平臺的建設；而騰訊內部的低代碼 Oteam 也在 21 年開始組織起來，主要的目標也是底層核心的共建。從整個行業(yè)看，低代碼引擎已經開始嶄露頭角，且可預見到趨勢還將上升。只是這個細分賽道更多可能只是大廠參與，因為其需要大量的場景支撐驗證，而這是小廠或獨立開發(fā)者不具備的。

總觀下來，差異化的平臺產品仍將是我們接觸低代碼領域的主要途徑；而低代碼引擎的出現(xiàn)，將為整個行業(yè)帶來更多的可能。

7、D2C 前端智能化未來可期

“前端智能化” 是近些年業(yè)界在前端 AI 方向上的新的探索。何謂智能化？就是將智能化算法結合前端工程化實踐，讓機器進行輔助開發(fā)。

D2C：歷史與現(xiàn)狀

截止目前，前端智能化領域最大規(guī)模落地的產品形態(tài)就是各種 Design to Code (下文簡稱 D2C) 工具：輸入 UI 設計稿，通過一系列算法，輸出可用的代碼。

2017 年一篇論文 pix2Code，提出了圖像生成代碼的想法。2018 年，微軟開源了 Sketch2Code 項目，進一步驗證了該方向的可行性。緊接著 2019 年，阿里淘系上線 imgcook，并在接下來的幾年里支撐了雙十一、618 等大量業(yè)務。這標志著 D2C 技術逐漸成熟，大規(guī)模業(yè)務落地勢在必行。

時間來到 2021，國內外各大公司都在此領域展開了相應的探索和實踐：騰訊 IMWeb 團隊啟動了 Project Auton，已經在內部上線試水，預計今年 6 月對外提供服務；阿里的 imgcook 依舊在持續(xù)進行快速迭代；字節(jié)內部基于低代碼平臺，孵化出了 “ALYX” 項目，也在內部展開了實踐；58 團隊開源了 Picasso; 轉轉上線了 ” 神筆馬良” 平臺 …

另外，D2C 領域也涌現(xiàn)出一批創(chuàng)業(yè)公司。如國內的 CodeFun 、藍湖，國外的 Framer 、Anima 等。值得一提的是 CodeFun，在易用性、還原度方面有相對較好的表現(xiàn)，上線后獲得了不錯的口碑。但在整個前端開源社區(qū)，目前 D2C 領域還沒有一個足夠有影響力的開源項目。因此各家也基本都處于 “閉門造車” 的狀態(tài)。

硬幣的兩面：缺陷、場景與機會

相對于早期基于純視覺算法的方案，目前大規(guī)模落地的 D2C 產品基本都是以設計稿源文件 (Sketch、Figma、XD 等) 作為原始輸入。由于純視覺算法很難從二維圖像上提取 UI 的層級等信息，而設計稿文件則可以通過解析內部 DSL 獲取更詳細的結構化 UI 描述，更方便進行后續(xù)的處理與代碼生成。

傳統(tǒng)的 pro-code 開發(fā)模式下，通常都是 “PRD 設計稿” 作為輸入，產出業(yè)務代碼。但 D2C 系統(tǒng)把設計稿作為唯一輸入，設計稿只是單純的 UI 描述，導致很多信息無法從設計中推斷出。如 動畫、交互、邏輯甚至是響應式等都無法單獨依靠 D2C 實現(xiàn)。由于這些缺陷，D2C 的場景大多也只是作為面向開發(fā)的輔助工具。距離真正的完全智能化（無需人工干預即可產出邏輯完備且生產環(huán)境可用的代碼）還為時尚早。

雖然存在上述諸多缺陷，但在 UI 開發(fā)這一領域，D2C 大有可為。

D2C 的產物 (組件 / 頁面代碼或描述 UI 的 DSL) 通常有如下幾種消費路徑：

1. 產出代碼，作為基礎 UI 組件，由開發(fā)者進行二次開發(fā)。
2. 產出代碼，作為基礎物料供給，結合 low-code/no-code 平臺進行二次編輯和編排。
3. 產出 DSL，結合定制化的 render 進行直接渲。

尤其是第二種消費路徑，借助近些年大熱的 low-code 平臺，對 D2C 產出的 UI 物料進行數(shù)據(jù)綁定、邏輯編排、樣式編輯、交互編排等人工干預和二次編輯，可以補全 D2C 的能力短板，并且建立出一套快速、高效、可沉淀、可復用的代碼生產 SOP。

另外， D2C 以其高效的供給效率，可以突破 low-code/no-code 的物料生產瓶頸，為前端的研發(fā)范式從 pro-code 走向 low-code 的變革加上了助推劑。

借助 D2C low-code/no-code，再結合近年來大熱的 SaaS、FaaS、BaaS 等技術產品形態(tài)，可預見地在不遠的未來，真的可以實現(xiàn)不需要工程師就可以零代碼快速上線一個數(shù)據(jù)、交互、邏輯完備的產品。這極大地降低了很多創(chuàng)新型業(yè)務的初期成本，甚至可能助推下一波互聯(lián)網創(chuàng)業(yè)浪潮，讓我們拭目以待。

不過目前為止，還沒有出現(xiàn)哪一個平臺能把上述幾種產品形態(tài) (D2C low-code/no-code SaaS/FaaS/BaaS) 完美地整合起來形成閉環(huán)，同時保持優(yōu)秀的用戶體驗。未來幾年，這個領域或許會催生出一些明星創(chuàng)業(yè)公司。

展望未來：深耕、整合、研發(fā)范式變革

展望 2022 年，可以預見前端業(yè)界智能化及 D2C 還將進行持續(xù)地發(fā)展，整體為如下兩大趨勢：

1. 縱向上：持續(xù)深耕，優(yōu)化流程、算法和體驗，讓 “智能化” 真正的越來越 “智能”。
2. 橫向上：建立標準和流程，打通整合上下游能力，串聯(lián) low-code、no-code、FaaS、BaaS、SaaS、設計體系、算法體系、研發(fā)體系、數(shù)據(jù)體系等… 真正形成工業(yè)化的快速生成體系，解放生產力。

從長遠來看，一旦上述體系建立起來，必將驅動業(yè)界開始下一次的研發(fā)模式變革。從目前的 pro-code 為主的研發(fā)模式，變革為 pro-code、low-code、no-code 三種模式相輔相成、互相供給和賦能的模式。同時由于標準化體系的建立，物料和產物都可以更容易實現(xiàn)通用和復用。這對于研發(fā)效能的提示無疑是巨大的！

這一些都充滿想象，即使智能化的路程中充滿質疑與險阻，但未來是值得期待的。新的一年還將繼續(xù)深耕和發(fā)展，2022 未來可期……

8、DevOps，研發(fā)效能仍是重點

研發(fā)效能是目前互聯(lián)網企業(yè)和傳統(tǒng)軟件企業(yè)都高度關注的領域，互聯(lián)網大廠希望通過 “研發(fā)效能” 實現(xiàn)持續(xù)的研發(fā)能力提升以應對日趨復雜的產品開發(fā)；腰部廠商則希望通過 “研發(fā)效能” 實現(xiàn)彎道超車，充分發(fā)揮后來者居上的優(yōu)勢；更多中小企業(yè)看到國內互聯(lián)網大廠不約而同地在這個領域重點投入，紛紛也是摩拳擦掌準備在效能領域發(fā)力。

和敏捷的概念類似，到底什么是研發(fā)效能很難精確定義。其實很多復雜概念也不是定義出來的，而是逐步演化出來的，是先有現(xiàn)象再找到合適的表述。其實，效率和效能也從來都不是軟件工程的專有名詞，縱觀人類發(fā)展史，就是生產力和生產效率不斷提升的發(fā)展篇章，到了數(shù)字化時代，軟件研發(fā)效能的重要性被凸顯了出來。如果要用一句話來總結研發(fā)效能的話，我們會用 “更高效、更高質量、更可靠、可持續(xù)地交付更優(yōu)的業(yè)務價值” 來總結。

我們能做的不是提升研發(fā)效能的絕對值，而是盡可能減緩研發(fā)效能惡化的程度，使其下降的不至于太快，努力保持現(xiàn)狀就是成功。

IMWeb 團隊在 DevOps 方面，2021 年有較大的進展。一方面，我們與騰訊云 Coding 在開發(fā)、測試、部署、運維等多個領域進行了共建，團隊自研的效能平臺 Thanos 與 Coding 團隊深度打造應用工作流方案，代理聯(lián)調平臺 TDE 與 Coding 團隊打通測試環(huán)境 Nohost 網關，接口聯(lián)調契約平臺 Tolstoy 與 Coding 共建 API 托管、Mock 和測試的能力。在研效大背景下，我們通過騰訊云 Coding 實現(xiàn)了效能平臺的大統(tǒng)一，整體研發(fā)效能提升 30% 以上。

9、微前端，不可輕視的一環(huán)

2016 年 ThoughtWorks 提出了微前端思想：將龐大的項目拆分成各個小型靈活項目，這些小項目互不干擾，可以獨立開發(fā)、獨立運行以及獨立部署，由此拉開微前端帷幕。在 2019 年阿里在 single-spa 基礎上開發(fā)了 qiankun 微前端框架后，微前端的熱度一直在增加。在微前端的發(fā)展過程中，開發(fā)者們也慢慢摸索出當下微前端的應用場景：

Image

時間來到 2021 年，微前端的框架已經非常多了，其中名聲比較響亮的有老牌的 single-spa，Github Star 數(shù)最高的微前端框架 qiankun，以及新興微前端框架京東的 MicroApp。

Image

single-spa 自 2020 年發(fā)布了 v5.0 后，在去年上半年主要工作還是圍繞 v5.0 一些 Bug 的修復，而在下半年 7 月份發(fā)布了 v6.0 的 beta 版本。雖然 v6.0 也有一些 Breaking Changes，但是對于這些 Changes，大多數(shù)用戶是不需要更新自己代碼的。其中比較重要的是在瀏覽器方面，v6.0 將是最后一個支持 IE11 的版本，且在以后的版本 v7.0 將不再支持 IE11，single-spa 團隊將會把更多精力從瀏覽器兼容轉到維護整個 single-spa 生態(tài)上。v6.0 還加入兩個新特性：

• 支持異步取消頁面導航。
• 暴露 patchHistoryApi，開發(fā)者可以使用 single-spa 封裝后的 pushState/replaceState/popstate/hashchange。

不僅老牌框架在發(fā)力，號稱 “可能是你見過最完善的微前端解決方案” qiankun 也在不斷更新。qiankun 主要還是解決不同應用場景的一些問題，以及修復沙箱中一些 JavaScript 的兼容問題，比如沙箱中的 defineProperty 問題，以及沙箱性能問題等。雖然 qiankun 在去年看起來沒太多更新，但是它也給出了令人激動的 V3.0 RoadMap，里面說到了非常多更新，主要更新有：獨立應用加載模塊以及獨立沙箱模塊。

不過，qiankun 依然沒有解決侵入性強的問題，并不能像類似 iframe 一樣很方便地嵌入頁面。

下半年一個好消息是，京東也推出了自己微前端的解決方案 MicroApp。它并沒有采用 single-spa 和 qiankun 的組件化思路，而是借鑒了 WebComponent 的思想，通過 CustomElement 結合自定義的 ShadowDom，將微前端封裝成一個類 WebComponent 組件，從而實現(xiàn)微前端的組件化渲染。它有以下特性：

• 類 WebComponent HTML Entry
• 生命周期
• 資源地址補全
• JS 沙箱、樣式隔離、元素隔離
• 數(shù)據(jù)通信
• 預加載
• 插件系統(tǒng)

MicroApp 在使用性和侵入性都做得非常完美，這個框架的發(fā)展和未來是非常值得期待的。

總的來說，微前端的基礎來自于“所有大型系統(tǒng)都逃不過熵增定律”，它能解決的問題也是解構一些巨石應用，所以微前端更多時候是 “悲觀主義工程師” 在工程上的妥協(xié)。對于是否要使用微前端，可以看 qiankun 作者 kuitos 在這篇《你可能并不需要微前端》里的分析。

IMWeb 團隊在過去的一年中也對微前端做了深度的調研，以 qiankun 為基礎完成了一次非常成功的 qiankun x 增量重構 的微前端實踐，將老的 Vue 巨石項目和新的 React 項目有機融合在一起，實現(xiàn)了并行開發(fā)以及無縫重構，極大提升前端的生產力。具體實踐細節(jié)可以關注 IMWeb 團隊公眾號后續(xù)的文章。

展望 2022 技術趨勢

業(yè)務可能會碰到瓶頸，但是技術的發(fā)展是永不止步的。只有 “厚積” 才能 “薄發(fā)”，前端人必須時刻磨煉自己，突破自身界限，才能在這個規(guī)范化、工業(yè)化、智能化、大統(tǒng)一化的時代走的更遠！

在細分領域方面，我們可以對 2022 年做一些展望：

• React 和 Vue 還是按照自身的特色在持續(xù)發(fā)展，重點還是圍繞著用戶體驗和開發(fā)者體驗兩塊。而黑馬 Svelte 是否能夠破局，以及 Svelte 新思潮的沖擊和影響，值得期待。
• 隨著全棧的深入發(fā)展，各大 UI 框架都有自己的 “元框架” 來構建全棧應用，再加上傳統(tǒng)大哥 Nest 和后起之秀 Remix，真可謂百家爭鳴。但后臺開發(fā)的深海不是某個框架能夠填平的，更需要的是前端開發(fā)者的意識與經驗積累，相信未來一年，前端會滲透的更加深入和全面。
• TypeScript 已經是前端項目的標配了，可以預計未來將會有更多強大的配套工具提高生產力還有提升使用體驗。
• 各大跨端框架都瞄準了桌面端，另外隨著 “云游戲” 的火熱，“云應用” 也非常有潛力，前端開發(fā)當然不能丟掉這個陣地了，Electron 的社區(qū)以及 Tauri 的性能都值得期待。
• 如果希望自己走的更遠，是時候學習一門新的語言了，JS 基礎設施的未來 —— Rust，全棧 —— Go，AI —— Python，F(xiàn)lutter —— Dart，前端人打破自身邊界，更待何時？未來 WASM 必定大火，無前端不識！
• ToB 的轉變趨勢明顯，低代碼大有可為，令人高興的是，更多的大廠趨向統(tǒng)一低代碼，開源引擎，結束低代碼平臺遍地跑的亂局，這也是互聯(lián)網行業(yè)走向工業(yè)化和智能化的必經途徑。
• D2C 是前端智能化的開端，道路還非常漫長，很期待更多的前端智能化產品落地！
• 研效平臺也處在大一統(tǒng)的階段，未來一年應該還會持續(xù)進行，雖然會有陣痛，但為了未來研發(fā)工業(yè)化與智能化，這個付出是值得的！
• 隨著 5G 網絡的普及和手機硬件的不斷提升，傳統(tǒng)的圖文媒體已經無法滿足廣大網民的胃口，相信未來音視頻領域還有非常大的發(fā)揮空間，在虛擬化和元宇宙時代未到之前，音視頻領域還是這個時代的核心。
• 隨著業(yè)務發(fā)展，管理系統(tǒng)不斷增長以及大統(tǒng)一的趨勢，巨石應用是不可避免并且會越來越多的，如果得了這個病，微前端不失為一方良藥，微前端的生態(tài)和建設、以及 MicroApp 借鑒 WebComponent 的思想都非常值得期待！