整體來看，從大的趨勢上沒有太大的變化。這里并不考慮某些特定的技術，而是從總體上（戰略）層面來看待問題。所以，就有了這么幾個點：

• 前端架構治理。
• 微前端“普及”
• 低代碼平臺的返璞
• 超越前端

看上去最后一點一直是如此，哈哈。

[[378407]]

前端架構治理

前端架構治理是一個頗為復雜的問題，我們限入了一個困境：要做的事情很多，但是無奈 JavaScript 的靈活性困擾了我們每一步。所以，在某些時候，我們所能治理的東西比較有限。常見的一些有：構建優化、組件化、微前端等。

大型前端應用

單個前端應用上了一定的規模，這本身是比較少見的 —— 從比例上來看。但是一旦遇到的時候，就往往需要大量地工作，才能治理好整個前端應用，還需要配合開發一些工具。好在市面上已經有大量的類似工具，也可以編寫如 Lemonj 這樣的輕量級自動化 CSS 重構工具。

說實話，如果我們管理不好 CSS 中的 color 變量，那么整體的規范性就會成為一個新的問題。

規范之旅

我本不想浪費時間在這個話題上，但是真的很無奈。

兄弟姐妹們，能用 TypeScript 就用 TypeScript，能綁定各種 Lint 就用各種 Lint，能用 Git Hooks + Husky 就加上吧！大型前端項目，有機會選擇 Angular 就用 Angular 吧！

微前端“普及”

從 2018 年，我開始推廣微前端架構至今，這種架構模式的基礎設施已經越來越成熟。我們可以明顯地看到，它已經從大型前端團隊的落地，開始進入小型前端團隊的視野里。而采用的主要意圖，也發生了一些變化。原先是以大型應用架構為主而采用微前端，而幾年之后，我經歷過地大量相關咨詢項目里，它變成以 演進式方案 而存在，即完成舊系統的平滑遷移。

微前端框架成熟

繼我寫了國內的第一個微前端框架 mooa 之后，國內誕生了越來越多的商業級微前端框架：qiankun、ngx-planet 等等。每一種框架都有各自地適用場景，這里就不一一展開。

唯一可以肯定的是： 這些框架很少能直接滿足大部分項目的需求 —— 因為業務特定的緣故。所以，我在過去的幾年時間里，設計了越來越多的微前端演進方案。

漸進式演進方案

對于一個正常業務開發的項目來說，微前端架構不是一蹴而就的，而是演進出來的。于是，也就衍生了相關的漸進式演進方案，如：

• 元微前端框架 。在 2020 年里，因為某公司需要一個更具競爭力地微前端框架，所以我聯想到了：元微前端框架。雖然，我沒有花時間去想象這樣的框架，但是已經有人采用了類似的思想。
• 多加載器模式 。對于微前端框架來說，從某種意義上來說，它只是一個應用加載器。我們通過這個加載器去加載不同框架的應用，如 qiankun 可以支持 Angular、Vue 和 React，而對于并非這種框架的應用來說，它們需要一個新的加載器。于是，多應用加載器模式孕育而生。
• 定制微前端框架。改造現有的微前端框架，使之適合于現有的業務架構。

因此，微前端作為一種前端遺留系統重寫的架構模式，它將越來越普及。

低代碼平臺的返璞

中臺火了幾年之后，被譽為“前端中臺”的低代碼平臺也在整個市場上越來越火爆。在這個行業里，開發人員劃分了三個領域 no code（無代碼 ）、low code（低代碼）、pro code（專業代碼），而當開發人員把這三個領域合并為一個系統時，這個系統就變得異常奇怪。

依我的觀點來看，既然面向的人群不一樣，面向的水平不一樣，那么我們應該有三個獨立的、拆開的系統。它們可以共享基礎設施，這不代表它們就是一個系統。

重塑用戶體驗

對于一個低代碼/無代碼平臺來說，平臺的復雜度主要是由其要承載的業務引起的。如果一個只是做 H5 又或者是表單的低代碼平臺來說，其本身設計不會過于復雜。而在場景變得越來越多時，系統變得愈發復雜，直至使用人員無法理解。

事物的發展是有其規律的，當平臺能滿足需求之后，自然而然下一步便是重塑用戶體驗。

構建開發者體驗

PS：這一小部分主要是從我的個人的角度來看，可能能代表一部分開發者。

從個人的角度來看，拖拉拽對于開發人員來說，它的 成本非常高 。可編碼的東西，如果可以通過按鍵來解決的放，那么它必然會提高效率。舉個簡單的例子，在設計低代碼平臺時，我們會對組件進行命名，如 header。那么，我們通過諸如于 VS Code 的 snippets 來直接生成表示頁面/組件的 DSL，必然會比我在頁面上拉拉扯扯快得多。

動態編寫 DSL 勝于拖拉拽。

超越前端

后端工程師，首先它是個工程師，然后它才是個后端工程師。前端工程師，首先它是個工程師，然后它才是個前端工程師。

在思考問題時，也應該從總體的角度來考慮問題，再從自身的角度來看怎樣全局優化，這便是資深程序員與普通程序員的區別。所以，站在更高的視角，看到的問題就不一樣，比如 BFF 的全局優化，比如 Serverless 架構等等。

Serverless 一體化

對于大量地小型應用來說，直接采用 Serverless + 小程序來說是一個非常便宜快速的方案。至少在前期的試錯成本非常之低，無需考慮服務器和并發等問題，也無需浪費大量地服務器資源。

不論使用的是什么技術棧，在 2021 年，你都應該試試 Serverless 架構了。

重回跨語言前端

Rust、Web Assembly 或者是 Kotlin，又或者是一些新興的語言，它們都可以以一種新的試，讓其它領域的開發人員編寫能運行在瀏覽器上的代碼。

最近的一年多里，在大家看來：我一直在忽悠前端開發人員寫 Rust。原因無非是，它的后臺是 Mozilla —— 可以快速運行在瀏覽器之上，又是系統編程語言 —— 可以嘗試大量非常有意思地傳統應用。

其它

最后，讓我用一個老生常談的問題，來結束這篇話題 —— 前端是選擇深度還是廣度？

這個問題的答案其實蠻簡單的，也蠻打擊人的。它取決于我們所在的團隊的規模，當團隊夠大的時候，我們就越有機會嘗試一些特別有意思的新技術，又或者是深入優化某一領域的技術。這個道理也適用于后端。