作者 | 雲謙
習慣從業務場景、用戶體驗、研發速度、維護成本四個維度來看框架等前端技術,大部分的技術點都能找到合適的位置,解的問題是如何快速上線和維護滿足業務的好用的產品。
業務場景
這部分解從框架的角度看業務需要。
框架負責,
- 對接後後端框架
- 對接輸出環節,包括支付寶容器,pc 和 mobile 瀏覽器,組件研發等
- 對接二方服務,包括統計,鑑權等
未來三年,
- 更多的業務有移動辦公需求,小程序會繼續加量
- 更多複雜場景的出現,包括重型應用,應用集群等,WebAssembly,微前端,Module Federation 等技術會在此發揮作用
- 標準應用中 NoCode/LowCode 的佔比逐漸增大,開發者逐漸習慣這種研發方式,包括雲鳳蝶或更垂直的 NoCode 平臺,imgcook 等
- 需要對接的業務場景越來越多,框架層需要做取捨、收斂和適時的減法
用戶體驗
什麼是默認好用?以及如何做到默認好用。
要有更好的用戶體驗,前端 + 設計師需負責,
- 前端尺寸要小,這樣頁面載入更快
- 合理的 Code Splitting、Bundle Splitting 和按需加載策略,這樣重要內容載入更快
- UI 好看,交互流暢且好用
- 合理的緩存和預加載策略,這樣頁面切換更快
之前覺得 5G 來了尺寸肯定不是問題,直到我看到需要下載 60M JS 資源的頁面,內網環境打開頁面都要 8s+。現在的圖形庫、UI 庫根本不把尺寸當回事。
未來三年,如果我們希望有更好的用戶體驗,
- 圖形庫、UI 庫自己得做瘦身/按需加載/正確的 tree-shaking/設計合理的按需編譯
- 更多框架層內置的性能優化方案
- 框架接管請求層,不止是發請求,基於路由,提供緩存和預加載策略
- 混合研發如果成為主流,需要解沙箱滿的問題,參考 tech ui 首頁,換 module federation 或者坐等瀏覽器實現標準的沙箱環境
研發速度
這部分解如何快速完成研發,並交付上線。
各方配合,不止是框架,
- 工具提速、框架瘦身、TS 定義等
- 組件封裝,包含 antd/antv/tech-ui
- 數據準備,包含 oneapi
- 交付流暢性,包含 DEMO 中心,MOCK 平臺,聯調最佳實踐等
- 輔助工具
未來三年,
- 編譯速度肯定會大幅提升,路肯定不止一條;重 CPU 部分會基於 Rust/Go 實現但不是整體,整體方案的終態我更傾向 npm pre-built cdn + bundless 的組合;這不止是框架/工具等事,ui 庫和工具庫也許合理規劃和配置,不然一個項目用 5 個圖形庫 + 10 個依賴 antd 等庫,10000+ 的文件要編譯,怎麼搞也是快不起來
- 更多垂直領域高級別的封裝,集成框架/UI/數據/數據流,快速產出中臺應用,形態可能是平臺,也可能是 ProCode;封裝等級越高,開發越快,但定製越難,需權衡
- 命令行在很多場景下不夠用,藉助輔助工具可進一步提效;形態有編輯器插件、Chrome 插件和 In-Context Editing
維護成本
產品不僅要開發,還要維護,何況框架和依賴庫還在不斷升級。
成本問題包括,
- 新人的上手成本
- 開發人員迭代的接手成本
- 技術棧升級成本
未來三年,對於框架而言,
- 降低技術棧升級成本。這需要框架有更好的頂層設計,更好的抽象,抹平底層技術棧,解 3-5 年後依賴的技術棧變更後遷移成本最小化的問題;功能方面權衡一方集成/二方提供/三方引入,設計上適度集成,適度組合,適度 eject
- 寫一樣的代碼。持續打磨最佳實踐,方案唯一化,一不是絕對的一,而是特定場景下的一;框架支持多端適配,未來是 PC + 小程序,長遠看,多套寫法應該走向統一
關注「Alibaba F2E」
把握阿里巴巴前端新動向