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

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

看上去最后一點(diǎn)一直是如此，哈哈。

[[378407]]

前端架構(gòu)治理

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

大型前端應(yīng)用

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

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

規(guī)范之旅

我本不想浪費(fèi)時(shí)間在這個(gè)話題上，但是真的很無奈。

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

微前端“普及”

從 2018 年，我開始推廣微前端架構(gòu)至今，這種架構(gòu)模式的基礎(chǔ)設(shè)施已經(jīng)越來越成熟。我們可以明顯地看到，它已經(jīng)從大型前端團(tuán)隊(duì)的落地，開始進(jìn)入小型前端團(tuán)隊(duì)的視野里。而采用的主要意圖，也發(fā)生了一些變化。原先是以大型應(yīng)用架構(gòu)為主而采用微前端，而幾年之后，我經(jīng)歷過地大量相關(guān)咨詢項(xiàng)目里，它變成以 演進(jìn)式方案 而存在，即完成舊系統(tǒng)的平滑遷移。

微前端框架成熟

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

唯一可以肯定的是： 這些框架很少能直接滿足大部分項(xiàng)目的需求 —— 因?yàn)闃I(yè)務(wù)特定的緣故。所以，我在過去的幾年時(shí)間里，設(shè)計(jì)了越來越多的微前端演進(jìn)方案。

漸進(jìn)式演進(jìn)方案

對于一個(gè)正常業(yè)務(wù)開發(fā)的項(xiàng)目來說，微前端架構(gòu)不是一蹴而就的，而是演進(jìn)出來的。于是，也就衍生了相關(guān)的漸進(jìn)式演進(jìn)方案，如：

• 元微前端框架 。在 2020 年里，因?yàn)槟彻拘枰粋€(gè)更具競爭力地微前端框架，所以我聯(lián)想到了：元微前端框架。雖然，我沒有花時(shí)間去想象這樣的框架，但是已經(jīng)有人采用了類似的思想。
• 多加載器模式 。對于微前端框架來說，從某種意義上來說，它只是一個(gè)應(yīng)用加載器。我們通過這個(gè)加載器去加載不同框架的應(yīng)用，如 qiankun 可以支持 Angular、Vue 和 React，而對于并非這種框架的應(yīng)用來說，它們需要一個(gè)新的加載器。于是，多應(yīng)用加載器模式孕育而生。
• 定制微前端框架。改造現(xiàn)有的微前端框架，使之適合于現(xiàn)有的業(yè)務(wù)架構(gòu)。

因此，微前端作為一種前端遺留系統(tǒng)重寫的架構(gòu)模式，它將越來越普及。

低代碼平臺的返璞

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

依我的觀點(diǎn)來看，既然面向的人群不一樣，面向的水平不一樣，那么我們應(yīng)該有三個(gè)獨(dú)立的、拆開的系統(tǒng)。它們可以共享基礎(chǔ)設(shè)施，這不代表它們就是一個(gè)系統(tǒng)。

重塑用戶體驗(yàn)

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

事物的發(fā)展是有其規(guī)律的，當(dāng)平臺能滿足需求之后，自然而然下一步便是重塑用戶體驗(yàn)。

構(gòu)建開發(fā)者體驗(yàn)

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

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

動態(tài)編寫 DSL 勝于拖拉拽。

超越前端

后端工程師，首先它是個(gè)工程師，然后它才是個(gè)后端工程師。前端工程師，首先它是個(gè)工程師，然后它才是個(gè)前端工程師。

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

Serverless 一體化

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

不論使用的是什么技術(shù)棧，在 2021 年，你都應(yīng)該試試 Serverless 架構(gòu)了。

重回跨語言前端

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

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

其它

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

這個(gè)問題的答案其實(shí)蠻簡單的，也蠻打擊人的。它取決于我們所在的團(tuán)隊(duì)的規(guī)模，當(dāng)團(tuán)隊(duì)夠大的時(shí)候，我們就越有機(jī)會嘗試一些特別有意思的新技術(shù)，又或者是深入優(yōu)化某一領(lǐng)域的技術(shù)。這個(gè)道理也適用于后端。