作者：騰訊 IMWeb 前端團(tuán)隊(duì)

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

• zx 工具包僅用了 7 個(gè)月就榮登全年 Star 增長(zhǎng)最快的項(xiàng)目，這側(cè)面表明了前端開(kāi)發(fā)在全棧的持續(xù)滲透和影響力。

• 在前端框架上面，龍頭 React 和 Vue 還是穩(wěn)步發(fā)展，持續(xù)創(chuàng)新。而黑馬 Svelte 在今年崛起，一舉超越 Angular 占據(jù)第三位，并對(duì)頭名虎視眈眈。那么 Svelte 能否破局？

• 在 Node.js 框架中，React 的 “元框架” Next.js 一騎絕塵。而新秀 Remix 僅僅 2 個(gè)月就沖到了第四，值得關(guān)注。

• 在構(gòu)建工具上面，對(duì)原生 ES 模塊的接納仍在繼續(xù)，vite 勢(shì)頭難擋，另一方面，出于對(duì)性能的考慮，越來(lái)越多的前端工具開(kāi)始用其他語(yǔ)言 (Rust、Go) 來(lái)構(gòu)建。

• 在桌面端，大火的 Tauri 打破了 Electron 的統(tǒng)治，基于 Rust (可替換)，Tauri 對(duì)比 Electron 有更小的包大小和內(nèi)存占用，未來(lái)可期。

接下來(lái)，主要盤(pán)點(diǎn)下 2021 年前端行業(yè)發(fā)生了哪些重要的事情，同時(shí)分享下騰訊 IMWeb 團(tuán)隊(duì)在過(guò)去一年中都做了哪些工作。

總結(jié) 2021 年度趨勢(shì)

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

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

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

從 Stack Overflow Developer Survey 2021 來(lái)看，TypeScript 受大家喜愛(ài)程度依舊在提升，估計(jì)在 2022 年還會(huì)保持增長(zhǎng)。

回顧

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

• 更好的元組類型支持，允許任意位置的剩余類型以及可選類型。

• 更好的模板字符串字面量類型支持。

• 更智能的條件分支域的類型推斷。

• 索引類型支持 Symbol 和模板字符串模式。

• Awaited 類型和 Promise 類型改進(jìn)。

除了特性，它還完善了許多使用體驗(yàn)，比如：

• 性能優(yōu)化如更快的類型生成、增量編譯和 Sourcemap 生成。

• 更智能的 IDE 補(bǔ)全。

• 非 Javascript 源文件定位。

另外， TypeScript 新官網(wǎng)在 8 月上線了，全新的文檔查閱起來(lái)也更加方便。

目前 TypeScript 已經(jīng)是 IMWeb 團(tuán)隊(duì)的標(biāo)配。無(wú)論是 Web 前端、Node.js 項(xiàng)目還是公共模塊，從腳手架模板就默認(rèn)支持 TypeScript，其中公共模塊體系不僅僅使用 TypeScript 編寫(xiě)代碼和類型檢查，同時(shí)利用 ESLint 實(shí)現(xiàn) TS 語(yǔ)言標(biāo)準(zhǔn) AST 的特定校驗(yàn)來(lái)實(shí)現(xiàn)公共模塊規(guī)范，還結(jié)合 TypeDoc 生成使用文檔等等。

展望

TypeScript 在未來(lái)將提供更多激動(dòng)人心的特性，例如：

• 扁平化聲明文件（Flattening declarations），只輸出一份總的 d.ts 文件，而不是一個(gè)模塊一個(gè) d.ts 文件。

• 環(huán)境裝飾器（Ambient decorators），用來(lái)聲明一些環(huán)境信息，例如 API 是否是 deprecated。不影響輸出的運(yùn)行時(shí)代碼，只在 d.ts 聲明文件中體現(xiàn)。

• 條件編譯（Conditional compilation），有點(diǎn)類似 C++ 中的 #if 宏定義，可以在編譯前預(yù)處理代碼并保留符合條件的代碼分支。

• 函數(shù)表達(dá)式以及箭頭函數(shù)的裝飾器（Decorators for function expressions/arrow functions），目前 TypeScript 中裝飾器只能用于 class 中，未來(lái)將可能支持類外的函數(shù)表達(dá)式以及箭頭函數(shù)使用裝飾器。

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

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

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

當(dāng) React 18 發(fā)布時(shí)，它將包含開(kāi)箱即用的改進(jìn)（如 Automatic batching)，全新的 API（如 startTransition）以及內(nèi)置支持了 React.lazy 的全新 SSR 架構(gòu)。這些功能之所以能夠?qū)崿F(xiàn)，要?dú)w功于在 React 18 中新加入的可選的 “并發(fā)渲染（concurrent rendering）” 機(jī)制，它為 React 解鎖了非常多新的可能性，來(lái)幫助你提高你應(yīng)用程序的實(shí)際與感知性能。

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

? Automatic batching

? SSR for Suspense

? New APIs for app and library developers

? Automatic batching

React 18 通過(guò)默認(rèn)執(zhí)行更多 batching (批處理) 來(lái)增加開(kāi)箱即用的性能改進(jìn)，無(wú)需在應(yīng)用程序或庫(kù)代碼中手動(dòng)批處理更新。batching 是指，React 可以將回調(diào)函數(shù)中多個(gè) setState 事件合并為一次渲染。

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

● SSR for Suspense

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

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

● New APIs for app and library developers

Concurrent APIs：

Concurrent Rendering 相關(guān)的變動(dòng)是 React 18 的主要變動(dòng)之一，簡(jiǎn)而言之，這個(gè)能力會(huì)讓 React 應(yīng)用保持更好的響應(yīng)性。這是一種可中斷渲染的設(shè)計(jì)架構(gòu)。什么時(shí)候中斷渲染呢？當(dāng)一個(gè)更高優(yōu)先級(jí)渲染到來(lái)時(shí)，通過(guò)放棄當(dāng)前的渲染，立即執(zhí)行更高優(yōu)先級(jí)的渲染，換來(lái)視覺(jué)上更快的響應(yīng)速度。

• useTransition：允許組件在切換到下一個(gè)界面之前等待內(nèi)容加載，從而避免不必要的加載狀態(tài)。

• startTransition：被 startTransition 回調(diào)包裹的 setState 觸發(fā)的渲染 被標(biāo)記為不緊急的渲染，這些渲染可能被其他緊急渲染所搶占。

• useDeferredValue：返回一個(gè)延遲響應(yīng)的值，例如一個(gè)選擇輸入框過(guò)濾列表的場(chǎng)景，我們可以針對(duì)列表使用 useDeferredValue 傳入選擇器對(duì)應(yīng)的值。

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

其他 APIs：

• useSyncExternalStore：useSyncExternalStore 將替代 useMutableSource 用于訂閱外部源，解決 Concurrent Rendering 可能導(dǎo)致的數(shù)據(jù)不一致的問(wèn)題，也是庫(kù)作者可能需要，一般開(kāi)發(fā)者不太能用到。

• useId：useId 用于在客戶端與服務(wù)端之間產(chǎn)生唯一 ID ，避免 SSR hydrate 時(shí)元素不匹配。

• useInsertionEffect：用于插入全局 DOM 節(jié)點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

靜待花開(kāi)的攪局者

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

4、桌面端 - 前端開(kāi)發(fā)的下一個(gè)戰(zhàn)場(chǎng)

持續(xù)擴(kuò)大桌面應(yīng)用領(lǐng)域影響

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

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

Electron

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

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

當(dāng)然，Electron 也并不是全無(wú)缺陷的，一些常受詬病的缺點(diǎn)有：

• 打包體積過(guò)大，由于捆綁了 Chromium 內(nèi)核等大量依賴，導(dǎo)致 Electron 的打包體積普遍在 100M+，這一點(diǎn)我們可以使用 asar 壓縮、動(dòng)態(tài)鏈接庫(kù)等方式進(jìn)行優(yōu)化。

• 內(nèi)存占用高，同樣的由于捆綁了 Chromium 內(nèi)核，Electron 的內(nèi)存占用普遍也較高。

• UI 層視覺(jué)渲染效率低，這一點(diǎn)也可以通過(guò)優(yōu)化手段，如多進(jìn)程處理任務(wù)、甚至利用視覺(jué)假象來(lái)提升用戶體驗(yàn)。

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

React Native Desktop

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

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

Flutter Desktop

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

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

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

Tauri

最近搭上 Rust 的東風(fēng)的 Tauri 受到非常多的關(guān)注，對(duì)標(biāo) Electron，主要有以下 4 點(diǎn)優(yōu)勢(shì)：

• 包體積大小更小

• 運(yùn)行時(shí)內(nèi)存占用更小

• 安全擺在第一位

• 真正的開(kāi)源

但是理性思考，對(duì)于前端開(kāi)發(fā)來(lái)說(shuō)，有三個(gè)致命的缺點(diǎn)：

• Tauri 使用系統(tǒng) webview，會(huì)有兼容性問(wèn)題，這也是 Electron 重點(diǎn)解決的問(wèn)題

• 拋棄了 nodejs，生態(tài)圈目前來(lái)說(shuō)還是很難比得上 Electron 的

• 底層開(kāi)發(fā)要用 Rust，有一定的上手成本

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

6、Rust-是時(shí)候掌握一門(mén)新語(yǔ)言了

Rust 是 JS 基礎(chǔ)設(shè)施的未來(lái)

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

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

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

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

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

前端人是時(shí)候?qū)W習(xí)一門(mén)新語(yǔ)言

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

比如，在工具鏈上，Rust 的 rustup 就相當(dāng)于 nvm，可以切換運(yùn)行工具 cargo（Rust 版的 npm）的版本，但它也比 nvm 強(qiáng)大，在安裝 rustup 的同時(shí)，還會(huì)安裝 clippy（Rust 版的 eslint）、rustfmt（Rust 版的 prettier），用 Rust 配套工具新建的項(xiàng)目就已經(jīng)帶有代碼格式化、分析配套的工具。

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

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

如果在以前說(shuō)前端可以去學(xué)習(xí)的第二語(yǔ)言是 C++，那么現(xiàn)在或許就是 Rust 了，它有著比 C++ 更現(xiàn)代化的依賴管理、語(yǔ)法、工具鏈，讓你不至于在一開(kāi)始就被勸退，還能讓你在前端領(lǐng)域更具競(jìng)爭(zhēng)力。

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

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

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

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

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

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

同時(shí)，我們也看到在今年底的 GMTC 大會(huì)上，阿里已經(jīng)對(duì)外宣傳了集團(tuán)的低代碼引擎，從分享內(nèi)容看已經(jīng)支撐了 60 多個(gè)低代碼平臺(tái)的建設(shè)；而騰訊內(nèi)部的低代碼 Oteam 也在 21 年開(kāi)始組織起來(lái)，主要的目標(biāo)也是底層核心的共建。從整個(gè)行業(yè)看，低代碼引擎已經(jīng)開(kāi)始嶄露頭角，且可預(yù)見(jiàn)到趨勢(shì)還將上升。只是這個(gè)細(xì)分賽道更多可能只是大廠參與，因?yàn)槠湫枰罅康膱?chǎng)景支撐驗(yàn)證，而這是小廠或獨(dú)立開(kāi)發(fā)者不具備的。

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

7、D2C 前端智能化未來(lái)可期

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

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

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

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

時(shí)間來(lái)到 2021，國(guó)內(nèi)外各大公司都在此領(lǐng)域展開(kāi)了相應(yīng)的探索和實(shí)踐：騰訊 IMWeb 團(tuán)隊(duì)啟動(dòng)了 Project Auton，已經(jīng)在內(nèi)部上線試水，預(yù)計(jì)今年 6 月對(duì)外提供服務(wù)；阿里的 imgcook 依舊在持續(xù)進(jìn)行快速迭代；字節(jié)內(nèi)部基于低代碼平臺(tái)，孵化出了 “ALYX” 項(xiàng)目，也在內(nèi)部展開(kāi)了實(shí)踐；58 團(tuán)隊(duì)開(kāi)源了 Picasso; 轉(zhuǎn)轉(zhuǎn)上線了 ” 神筆馬良” 平臺(tái) ...

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

硬幣的兩面：缺陷、場(chǎng)景與機(jī)會(huì)

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

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

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

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

產(chǎn)出代碼，作為基礎(chǔ) UI 組件，由開(kāi)發(fā)者進(jìn)行二次開(kāi)發(fā)。

產(chǎn)出代碼，作為基礎(chǔ)物料供給，結(jié)合 low-code/no-code 平臺(tái)進(jìn)行二次編輯和編排。

產(chǎn)出 DSL，結(jié)合定制化的 render 進(jìn)行直接渲。

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

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

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

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

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

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

縱向上：持續(xù)深耕，優(yōu)化流程、算法和體驗(yàn)，讓 “智能化” 真正的越來(lái)越 “智能”。

橫向上：建立標(biāo)準(zhǔn)和流程，打通整合上下游能力，串聯(lián) low-code、no-code、FaaS、BaaS、SaaS、設(shè)計(jì)體系、算法體系、研發(fā)體系、數(shù)據(jù)體系等... 真正形成工業(yè)化的快速生成體系，解放生產(chǎn)力。

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

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

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

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

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

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

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

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

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

Image

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

Image

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

• 支持異步取消頁(yè)面導(dǎo)航。

• 暴露 patchHistoryApi，開(kāi)發(fā)者可以使用 single-spa 封裝后的 pushState/replaceState/popstate/hashchange。

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

不過(guò)，qiankun 依然沒(méi)有解決侵入性強(qiáng)的問(wèn)題，并不能像類似 iframe 一樣很方便地嵌入頁(yè)面。

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

• 類 WebComponent + HTML Entry

• 生命周期

• 資源地址補(bǔ)全

• JS 沙箱、樣式隔離、元素隔離

• 數(shù)據(jù)通信

• 預(yù)加載

• 插件系統(tǒng)

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

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

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

展望 2022 技術(shù)趨勢(shì)

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

在細(xì)分領(lǐng)域方面，我們可以對(duì) 2022 年做一些展望：

• React 和 Vue 還是按照自身的特色在持續(xù)發(fā)展，重點(diǎn)還是圍繞著用戶體驗(yàn)和開(kāi)發(fā)者體驗(yàn)兩塊。而黑馬 Svelte 是否能夠破局，以及 Svelte 新思潮的沖擊和影響，值得期待。

• 隨著全棧的深入發(fā)展，各大 UI 框架都有自己的 “元框架” 來(lái)構(gòu)建全棧應(yīng)用，再加上傳統(tǒng)大哥 Nest 和后起之秀 Remix，真可謂百家爭(zhēng)鳴。但后臺(tái)開(kāi)發(fā)的深海不是某個(gè)框架能夠填平的，更需要的是前端開(kāi)發(fā)者的意識(shí)與經(jīng)驗(yàn)積累，相信未來(lái)一年，前端會(huì)滲透的更加深入和全面。

• TypeScript 已經(jīng)是前端項(xiàng)目的標(biāo)配了，可以預(yù)計(jì)未來(lái)將會(huì)有更多強(qiáng)大的配套工具提高生產(chǎn)力還有提升使用體驗(yàn)。

• 各大跨端框架都瞄準(zhǔn)了桌面端，另外隨著 “云游戲” 的火熱，“云應(yīng)用” 也非常有潛力，前端開(kāi)發(fā)當(dāng)然不能丟掉這個(gè)陣地了，Electron 的社區(qū)以及 Tauri 的性能都值得期待。

• 如果希望自己走的更遠(yuǎn)，是時(shí)候?qū)W習(xí)一門(mén)新的語(yǔ)言了，JS 基礎(chǔ)設(shè)施的未來(lái) —— Rust，全棧 —— Go，AI —— Python，Flutter —— Dart，前端人打破自身邊界，更待何時(shí)？未來(lái) WASM 必定大火，無(wú)前端不識(shí)！

• ToB 的轉(zhuǎn)變趨勢(shì)明顯，低代碼大有可為，令人高興的是，更多的大廠趨向統(tǒng)一低代碼，開(kāi)源引擎，結(jié)束低代碼平臺(tái)遍地跑的亂局，這也是互聯(lián)網(wǎng)行業(yè)走向工業(yè)化和智能化的必經(jīng)途徑。

• D2C 是前端智能化的開(kāi)端，道路還非常漫長(zhǎng)，很期待更多的前端智能化產(chǎn)品落地！

• 研效平臺(tái)也處在大一統(tǒng)的階段，未來(lái)一年應(yīng)該還會(huì)持續(xù)進(jìn)行，雖然會(huì)有陣痛，但為了未來(lái)研發(fā)工業(yè)化與智能化，這個(gè)付出是值得的！

• 隨著 5G 網(wǎng)絡(luò)的普及和手機(jī)硬件的不斷提升，傳統(tǒng)的圖文媒體已經(jīng)無(wú)法滿足廣大網(wǎng)民的胃口，相信未來(lái)音視頻領(lǐng)域還有非常大的發(fā)揮空間，在虛擬化和元宇宙時(shí)代未到之前，音視頻領(lǐng)域還是這個(gè)時(shí)代的核心。

• 隨著業(yè)務(wù)發(fā)展，管理系統(tǒng)不斷增長(zhǎng)以及大統(tǒng)一的趨勢(shì)，巨石應(yīng)用是不可避免并且會(huì)越來(lái)越多的，如果得了這個(gè)病，微前端不失為一方良藥，微前端的生態(tài)和建設(shè)、以及 MicroApp 借鑒 WebComponent 的思想都非常值得期待！

總結(jié)

以上是生活随笔為你收集整理的2021 大前端技术回顾及未来展望的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。