前端技術未來三年前瞻性思考

作者 | 雲謙

習慣從業務場景、使用者體驗、研發速度、維護成本四個次元來看架構等前端技術，大部分的技術點都能找到合适的位置，解的問題是如何快速上線和維護滿足業務的好用的産品。

業務場景

這部分解從架構的角度看業務需要。

架構負責，

1. 對接後後端架構
2. 對接輸出環節，包括支付寶容器，pc 和 mobile 浏覽器，元件研發等
3. 對接二方服務，包括統計，鑒權等

未來三年，

1. 更多的業務有移動辦公需求，小程式會繼續加量
2. 更多複雜場景的出現，包括重型應用，應用叢集等，WebAssembly，微前端，Module Federation 等技術會在此發揮作用
3. 标準應用中 NoCode/LowCode 的占比逐漸增大，開發者逐漸習慣這種研發方式，包括雲鳳蝶或更垂直的 NoCode 平台，imgcook 等
4. 需要對接的業務場景越來越多，架構層需要做取舍、收斂和适時的減法

使用者體驗

什麼是預設好用？以及如何做到預設好用。

要有更好的使用者體驗，前端 + 設計師需負責，

1. 前端尺寸要小，這樣頁面載入更快
2. 合理的 Code Splitting、Bundle Splitting 和按需加載政策，這樣重要内容載入更快
3. UI 好看，互動流暢且好用
4. 合理的緩存和預加載政策，這樣頁面切換更快

之前覺得 5G 來了尺寸肯定不是問題，直到我看到需要下載下傳 60M JS 資源的頁面，内網環境打開頁面都要 8s+。現在的圖形庫、UI 庫根本不把尺寸當回事。

未來三年，如果我們希望有更好的使用者體驗，

1. 圖形庫、UI 庫自己得做瘦身/按需加載/正确的 tree-shaking/設計合理的按需編譯
2. 更多架構層内置的性能優化方案
3. 架構接管請求層，不止是發請求，基于路由，提供緩存和預加載政策
4. 混合研發如果成為主流，需要解沙箱滿的問題，參考 tech ui 首頁，換 module federation 或者坐等浏覽器實作标準的沙箱環境

研發速度

這部分解如何快速完成研發，并傳遞上線。

各方配合，不止是架構，

1. 工具提速、架構瘦身、TS 定義等
2. 元件封裝，包含 antd/antv/tech-ui
3. 資料準備，包含 oneapi
4. 傳遞流暢性，包含 DEMO 中心，MOCK 平台，聯調最佳實踐等
5. 輔助工具

1. 編譯速度肯定會大幅提升，路肯定不止一條；重 CPU 部分會基于 Rust/Go 實作但不是整體，整體方案的終态我更傾向 npm pre-built cdn + bundless 的組合；這不止是架構/工具等事，ui 庫和工具庫也許合理規劃和配置，不然一個項目用 5 個圖形庫 + 10 個依賴 antd 等庫，10000+ 的檔案要編譯，怎麼搞也是快不起來
2. 更多垂直領域進階别的封裝，內建架構/UI/資料/資料流，快速産出中台應用，形态可能是平台，也可能是 ProCode；封裝等級越高，開發越快，但定制越難，需權衡
3. 指令行在很多場景下不夠用，借助輔助工具可進一步提效；形态有編輯器插件、Chrome 插件和 In-Context Editing

維護成本

産品不僅要開發，還要維護，何況架構和依賴庫還在不斷更新。

成本問題包括，

1. 新人的上手成本
2. 開發人員疊代的接手成本
3. 技術棧更新成本

未來三年，對于架構而言，

1. 降低技術棧更新成本。這需要架構有更好的頂層設計，更好的抽象，抹平底層技術棧，解 3-5 年後依賴的技術棧變更後遷移成本最小化的問題；功能方面權衡一方內建/二方提供/三方引入，設計上适度內建，适度組合，适度 eject
2. 寫一樣的代碼。持續打磨最佳實踐，方案唯一化，一不是絕對的一，而是特定場景下的一；架構支援多端适配，未來是 PC + 小程式，長遠看，多套寫法應該走向統一

關注「Alibaba F2E」

把握阿裡巴巴前端新動向