聊聊國(guó)內(nèi)前端的三大怪談

說實(shí)話，我試圖解釋了 19 年國(guó)內(nèi)的現(xiàn)狀，以及微信小程序推出時(shí)候所帶來的便利和體驗(yàn)等等。總之，在我看來并不夠深刻的見解。

即便到現(xiàn)在為止，每次當(dāng)我使用小程序的時(shí)候，依舊會(huì)復(fù)現(xiàn)這個(gè)問題。在 ChatGPT 11 月份出來的時(shí)候，我也問了它這個(gè)很有國(guó)內(nèi)特色的問題：

看起來它回答的還算不錯(cuò)，至少我想如果它來糊弄那些老外，應(yīng)該會(huì)比我做的更好些。

但如果捫心自問，單從技術(shù)上來講。以上這些事情，一定是有其他方案能解決的。

所以從某種程度上來看，這更像是一場(chǎng)截胡的商業(yè)案例：

應(yīng)用市場(chǎng)

全世界的互聯(lián)網(wǎng)人都知道應(yīng)用市場(chǎng)是非常有價(jià)值的事情，可以說操作系統(tǒng)最值錢的部分就在于他們構(gòu)建了自己的應(yīng)用市場(chǎng)。

只要應(yīng)用在這里注冊(cè)發(fā)行，雁過拔毛，這家公司就是互聯(lián)網(wǎng)世界里的統(tǒng)治階級(jí)，規(guī)則的制定者。

反之則需要受制于人，APP 做的再大，也只是應(yīng)用市場(chǎng)里的一個(gè)應(yīng)用，做的好與壞還得讓應(yīng)用商店的評(píng)判。

另外，不得不承認(rèn)的是，一個(gè)龐大如蘋果谷歌這樣的公司，他們的應(yīng)用商店對(duì)于普通國(guó)內(nèi)開發(fā)者來說，確實(shí)是有門檻的。

在國(guó)內(nèi)海量的 APP 需求來臨之前，能否提供一個(gè)更低成本的解決方案，來消化這些公司的投資？

畢竟不是所有的小企業(yè)都需要 APP，其實(shí)他們大部分需求 Web 就可以解決，但是 Web 沒牌面啊，做 Web 還得砸搜索的錢才有流量。(某度搜索又做成那樣...)

那做操作系統(tǒng)？太不容易，那么多人都溺死在水里了，這水太深。

那有沒有一種辦法可以既能構(gòu)建生態(tài)，又有 APP 的心智，還能給入駐企業(yè)提供流量？

于是，在 19 年夏天，濱海大廈下的軟件展業(yè)基地里，每天都在輪番播放著，做 XX小程序，擁抱下一個(gè)風(fēng)口...

全新體驗(yàn)心智

小程序用起來挺方便的。

你有沒有想過，這些美妙感覺的具體都來自哪些？以及這些真的是 Web 技術(shù)本身無法提供的嗎？

1. 靠譜感，每個(gè)小程序都有約束和規(guī)范，于是你可以將他們整整齊齊的陳放在你的列表里，仿佛你已經(jīng)擁有了這一個(gè)個(gè)精心雕琢的作品，相對(duì)于一條條記不住的網(wǎng)頁地址和魚龍混雜的網(wǎng)頁內(nèi)容來說，這讓你覺得小程序更加的有分量和靠譜。
2. 安全感，沉浸式的頭部，沒有一閃而過的加載條，這一切無打擾的設(shè)計(jì)，都讓你覺得這是一個(gè)在你本地的 APP，而不是隨時(shí)可能丟失網(wǎng)頁。你不會(huì)因?yàn)榫W(wǎng)速白屏而感到焦慮，盡管網(wǎng)絡(luò)差的時(shí)候，你的 KFC 依舊下不了單 ??
3. 沉浸感，我不知道是否打開網(wǎng)頁時(shí)頂部黑黑的狀態(tài)欄是故意留下的，還是不小心的... 這些限制都讓用戶非常強(qiáng)烈的意識(shí)到這是一個(gè)網(wǎng)頁而不是 APP，而小程序中雖然上面也存在一個(gè)空間的空白，但是卻可以被更加沉浸的主題色和氛圍圖替代。網(wǎng)頁這個(gè)需求做不了？我不信。

H5	小程序

4. 順滑感，得益于 Native 的容器實(shí)現(xiàn)，小程序在所有的視圖切換時(shí)，都可以表現(xiàn)出于原生應(yīng)用一樣的順滑感。其實(shí)這個(gè)問題才是在很多 Hybrid 應(yīng)用中，主要想借助客戶端來處理和解決的問題。類似容器預(yù)開、容器切換等技術(shù)是可以解決相關(guān)問題的，只是還沒有一個(gè)標(biāo)準(zhǔn)。

我這里沒有提性能，說實(shí)話我不認(rèn)為性能在小程序中是有優(yōu)勢(shì)的（Native 調(diào)用除外，如地圖等，不是一個(gè)討論范疇）。作為普通用戶，我們感受到的只是離線加載下帶來的順滑而已。

而上述提到的許多優(yōu)勢(shì)，這對(duì)于一個(gè)高品質(zhì)的 Web 應(yīng)用來說是可以做得到的，但注意這里是高品質(zhì)的 Web 應(yīng)用。而這種“高品質(zhì)”在小程序這里，只是入駐門檻而已。

心智，這個(gè)詞，聽起來很黑話，但卻很恰當(dāng)。當(dāng)小程序通過長(zhǎng)期這樣的篩選，所沉淀出來一批這樣品質(zhì)的應(yīng)用時(shí)。就會(huì)讓每個(gè)用戶即便在還沒打開一個(gè)新的小程序之前，也有不錯(cuò)體驗(yàn)的心理預(yù)期。這就是心智，一種感覺跟 Web 不一樣，跟 APP 有點(diǎn)像的心智。

打造心智，這件事情好像就是國(guó)內(nèi)互聯(lián)網(wǎng)企業(yè)最擅長(zhǎng)做的事情，總是能從一些細(xì)微的差別中開辟一條獨(dú)立的領(lǐng)域，然后不斷強(qiáng)化灌輸本來就不大的差異，等流量起來再去撈錢變現(xiàn)。

我總是感覺現(xiàn)在的互利網(wǎng)充斥著如何賺錢的想法，好像永遠(yuǎn)賺不夠。“賺錢”這個(gè)事情，在這些公司眼里就是圈人圈地?fù)屬Y源，看看誰先占得先機(jī)，別人有的我也得有，這好像是最重要的事情。

很少有企業(yè)在思考如何創(chuàng)造些沒有的市場(chǎng)，創(chuàng)造些真正對(duì)技術(shù)發(fā)展有貢獻(xiàn)，對(duì)社會(huì)發(fā)展有推動(dòng)作用的事情。所以在國(guó)內(nèi)互聯(lián)網(wǎng)圈也充斥著一種奇怪的價(jià)值觀，有技術(shù)的不一定比賺過錢的受待見。

管你是 PHP 還是 GO，管你是在做游戲還是直播帶貨，只要賺到錢就是高人。并且端的是理所應(yīng)當(dāng)、理直氣壯，有些老板甚至把拍攝滿屋子的程序員為自己打工作為一種樂趣。什么情懷、什么優(yōu)雅、什么愿景，人生就倆字：搞錢。

不是故意高雅，賺錢這件事情本身不寒磣，只是在已經(jīng)賺到盆滿缽滿、一家獨(dú)大的時(shí)候還在只是想著賺更多的錢，好像賺錢的目的就是為了賺錢一樣，這就有點(diǎn)不合適。企業(yè)到一定程度是要有社會(huì)責(zé)任的，龍頭企業(yè)每一個(gè)決定和舉措，都有會(huì)影響接下來的幾年里這個(gè)行業(yè)的價(jià)值觀走向。

?

當(dāng)然也不是完全沒有好格局的企業(yè)，我非常珍惜每一個(gè)值得尊重的中國(guó)企業(yè)，來自一個(gè)蔚來車主。

?

小程序在商業(yè)上固然是成功的，但吃的紅利可以說還是來自 網(wǎng)頁 到 應(yīng)用 的心智變革。將本來流向 APP 的紅利，截在了小程序生態(tài)里。

但對(duì)于技術(shù)生態(tài)的發(fā)展卻是帶來了無數(shù)條新的岔路，小程序的玩法就決定了它必須生長(zhǎng)在某個(gè)巨型應(yīng)用里面，不論是用戶數(shù)據(jù)獲取、還是 API 的調(diào)用，其實(shí)都是取決于應(yīng)用容器的標(biāo)準(zhǔn)規(guī)范。

不同公司和應(yīng)用之間則必然會(huì)產(chǎn)生差異，并且這種差異是墑增式的差異，只會(huì)隨著時(shí)間的推移越變?cè)酱蟆Ｈ绻總€(gè)企業(yè)都只關(guān)注到自己業(yè)務(wù)的增長(zhǎng)，無外部約束的話，企業(yè)必然會(huì)根據(jù)自己的業(yè)務(wù)發(fā)展和政策需要，選擇成本較低的調(diào)整 API，甚至?xí)室庵圃煲恍┍趬緛碓黾舆@種差異。

「小程序，應(yīng)該是 瀏覽器 與 操作系統(tǒng) 的融合，這本應(yīng)該是推動(dòng)這兩項(xiàng)技術(shù)操刀解決的事情。」

二、微前端

qiankun、wujie、single-spa 是近兩年火遍前端的技術(shù)方案，同樣一個(gè)問題：我們?yōu)槭裁葱枰⑶岸耍?/p>

我不確定是否每個(gè)在使用這項(xiàng)技術(shù)的前端都想清楚了這個(gè)問題，但至少在我面試過的候選人中，我很少遇到對(duì)自己項(xiàng)目中已經(jīng)在使用的微前端，有很深的思考和理解的人。

先說下我的看法：

1. 「微前端，重在解決項(xiàng)目管理而不在用戶體驗(yàn)。」
2. 「微前端，解決不了該優(yōu)化和需要規(guī)范的問題。」
3. 「微前端，在挽救沒想清楚 MPA 的 SPA 項(xiàng)目。」

沒有萬能銀彈

?

銀色子彈（英文：Silver Bullet），或者稱“銀彈”“銀質(zhì)子彈”，指由純銀質(zhì)或鍍銀的子彈。在歐洲民間傳說及19世紀(jì)以來哥特小說風(fēng)潮的影響下，銀色子彈往往被描繪成具有驅(qū)魔功效的武器，是針對(duì)狼人、吸血鬼等超自然怪物的特效武器。后來也被比喻為具有極端有效性的解決方法，作為殺手锏、最強(qiáng)殺招、王牌等的代稱。

?

所有技術(shù)的發(fā)展都是建立在前一項(xiàng)技術(shù)的基礎(chǔ)之上，但技術(shù)依賴的選擇過程中一定需要保留第一性原理的意識(shí)。

當(dāng) React、Vue 興起，當(dāng) 打包技術(shù)(Webpack) 興起，當(dāng) 網(wǎng)頁應(yīng)用(SPA) 興起，這些杰出的技術(shù)突破都在不同場(chǎng)景和領(lǐng)域中給行業(yè)提供了新的思路、新的方案。

不知從何時(shí)開始，前端除了 div 竟說不出其他的標(biāo)簽(還有說 View 的)，項(xiàng)目中再也不會(huì)考慮給一個(gè)通用的 class 解決通用樣式問題。

不知從何時(shí)開始，有沒有權(quán)限需要等到 API 請(qǐng)求過后才知道，沒有權(quán)限的話再把頁面跳轉(zhuǎn)過去申請(qǐng)。

不知從何時(shí)開始，大家的頁面都放在了一個(gè)項(xiàng)目里，兩個(gè)這樣的巨石應(yīng)用融合竟然變成了一件困難的事。

上面這些不合理的現(xiàn)狀，都是在不同的場(chǎng)景下，不思考適不適合，單一信奉 “一招吃遍天” 下演化出的問題。

「B 端應(yīng)用，是否應(yīng)該使用 SPA？」 這其實(shí)是一個(gè)需要思考的問題。

微前端從某種程度上來講，是認(rèn)準(zhǔn) SPA 了必須是互聯(lián)網(wǎng)下一代應(yīng)用標(biāo)準(zhǔn)的產(chǎn)物，好像有了 SPA 以后，MPA 就變得一文不值。甭管頁面是移動(dòng)端的還是PC的；甭管頁面是面對(duì) C 端的還是 B 端的；甭管一個(gè)系統(tǒng)是有 20 個(gè)頁面還是 200 個(gè)頁面，一律行這套邏輯。

SPA 不是萬能銀彈，React 不是萬能銀彈，Tailwind 不是萬能銀彈。在新技術(shù)出現(xiàn)的時(shí)候，保持熱情也要保持克制。

?

ps. 我也十分痛恨 React 帶來的這種壟斷式的生態(tài)，一個(gè) React 組件將 HTML 和 Style 都吃進(jìn)去，讓你即使在做一個(gè)移動(dòng)端的純展示頁面時(shí)，也需要背上這些稱重的負(fù)擔(dān)。

?

「質(zhì)疑 “墨守成規(guī)”，打開視野，深度把玩，理性消費(fèi)。」

分而治之

分治法，一個(gè)很基本的工程思維。

在我看來在一個(gè)正常商業(yè)迭代項(xiàng)目中的主要維護(hù)者，最好不要超過 3 個(gè)人，注意是主要維護(hù)者(Maintainer) 。

你應(yīng)該讓每個(gè)項(xiàng)目都有清晰的責(zé)任人，而不是某行代碼，某個(gè)模塊。責(zé)任人的理解是有歸屬感，有邊界感的那種，不是口頭意義上的責(zé)任人。(一些公司喜歡搞這種虛頭巴腦的事情，什么連坐…)

我想大部分想引入微前端的需求都是類似 如何更好的劃分項(xiàng)目邊界，同時(shí)保留更好的團(tuán)隊(duì)協(xié)同。

比如 導(dǎo)航菜單 應(yīng)該是獨(dú)立收口獨(dú)立管理的，并且當(dāng)其更新時(shí)，應(yīng)該同時(shí)應(yīng)用于所有頁面中。類似的還有 環(huán)境變量、時(shí)區(qū)、主題、監(jiān)控及埋點(diǎn)。微前端將這些歸納在主應(yīng)用中。

而具體的頁面內(nèi)容，則由對(duì)應(yīng)的業(yè)務(wù)進(jìn)行開發(fā)子應(yīng)用，最后想辦法將路由關(guān)系注冊(cè)進(jìn)主應(yīng)用即可。

當(dāng)然這樣純前端的應(yīng)用切換，還會(huì)出現(xiàn)不同應(yīng)用之間的全局變量差異、樣式污染等問題，需要提供完善的沙箱容器、隔離環(huán)境、應(yīng)用之間通信等一系列問題，這里不展開。

當(dāng)微前端做到這一部分的時(shí)候，我不禁在想，這好像是在用 JavaScript 實(shí)現(xiàn)一個(gè)瀏覽器的運(yùn)行容器。這種本應(yīng)該瀏覽器本身該做的事情，難道 JS 可以做的更好？

只是做到更好的項(xiàng)目拆分，組織協(xié)同的話，引入后端服務(wù)，由后端管控路由表和頁面規(guī)則，將頁面直接做成 MPA，這個(gè)方案或許并不比引入微前端成本高多少。

體驗(yàn)差異

從 SPA 再回 MPA，說了半天不又回去了么。

所以不防想想：在 B端 業(yè)務(wù)中使用 SPA 的優(yōu)勢(shì)在哪里？

流暢的用戶體驗(yàn)：

這個(gè)話題其實(shí)涵蓋范圍很廣，對(duì)于 SPA 能帶來的 “流暢體驗(yàn)”，對(duì)于大多數(shù)情況下是指：「導(dǎo)航菜單不變，內(nèi)容變化 發(fā)生變化，頁面切換中間不出現(xiàn)白屏」。

但要做到這個(gè)點(diǎn)，其實(shí)對(duì)于 MPA 其實(shí)并沒有那么困難，你只需要保證你的 FCP 在 500ms 以內(nèi)就行。

以上的頁面切換全部都是 MPA 的多頁面切換，我們只是簡(jiǎn)單做了導(dǎo)航菜單的 拆分 和 SWR，并沒有什么特殊的 preload、prefetch 處理，就得到了這樣的效果。

因?yàn)闉g覽器本身在頁面切換時(shí)會(huì)在 unload 之前先 hold 當(dāng)前頁面的視圖不變，發(fā)起一下一個(gè) document 的請(qǐng)求，當(dāng)頁面的視圖渲染做到足夠快和界面結(jié)構(gòu)穩(wěn)定就可以得到這樣的效果。

?

這項(xiàng)瀏覽器的優(yōu)化手段我找了很久，想找一篇關(guān)于它的博文介紹，但確實(shí)沒找到相關(guān)內(nèi)容，所以 500ms 也是我的一個(gè)大致測(cè)算，如果你知道相關(guān)的內(nèi)容，可以在評(píng)論區(qū)補(bǔ)充，不勝感激。

?

所以從這個(gè)角度來看，瀏覽器本身就在盡最大的努力做這些優(yōu)化，并且他們的優(yōu)化會(huì)更底層、更有效的。

離線訪問 (PWA)

SPA 確實(shí)會(huì)有更好的 PWA 組織能力，一個(gè)完整的 SPA 應(yīng)用甚至可以只針對(duì)編譯層做改動(dòng)就可以支持 PWA 能力。

但如果看微前端下的 SPA 應(yīng)用，需要支持 PWA 那就同樣需要分析各子應(yīng)用之間的元數(shù)據(jù)，定制 Service Worker。這種組織關(guān)系和定制 SW，對(duì)于元數(shù)據(jù)對(duì)于數(shù)據(jù)是來自前端還是后端，并不在意。

也就是說微前端模式下的 PWA，同樣的投入成本，把頁面都管理在后端服務(wù)中的 MPA 應(yīng)用也是可以做到相同效果的。

項(xiàng)目協(xié)同、代碼復(fù)用

有人說 SPA 項(xiàng)目下，項(xiàng)目中的組件、代碼片段是可以相互之間復(fù)用的，在 MPA 下就相對(duì)麻煩。

這其實(shí)涉及到項(xiàng)目劃分的領(lǐng)域，還是要看具體的需求也業(yè)務(wù)復(fù)雜度來定。如果說整個(gè)系統(tǒng)就是二三十個(gè)頁面，這做成 SPA 使用前端接管路由高效簡(jiǎn)單，無可厚非。

但如果你本身在面對(duì)的是一個(gè)服務(wù)于復(fù)雜業(yè)務(wù)的 B 端系統(tǒng)，比如類似 阿里云、教務(wù)系統(tǒng)、ERP 系統(tǒng)或者一些大型內(nèi)部系統(tǒng)，這種往往需要多團(tuán)隊(duì)合作開發(fā)。這種時(shí)候就需要跟完善的項(xiàng)目劃分、組織協(xié)同和系統(tǒng)整合的方案。

這個(gè)時(shí)候 SPA 所體現(xiàn)出的優(yōu)勢(shì)在這樣的訴求下就會(huì)相對(duì)較弱，在同等投入的情況下 MPA 的方案反而會(huì)有更少的執(zhí)行成本。

?

也不是所有項(xiàng)目一開始就會(huì)想的那么清楚，或許一開始的時(shí)候就是個(gè)簡(jiǎn)單的 SPA 項(xiàng)目，但是隨著項(xiàng)目的不斷迭代，才變成了一個(gè)個(gè)復(fù)雜的巨石應(yīng)用，現(xiàn)在如果再拆出來也會(huì)有許多遷移成本。引入微前端，則可以...

?

這大概是許多微前端項(xiàng)目啟動(dòng)的背景介紹，我想說的是：「對(duì)于屎山，我從來不信奉“四兩撥千斤”」。

如果沒有想好當(dāng)下的核心問題，就引入新的“銀彈”解決問題，只會(huì)是屎山雕花。

項(xiàng)目協(xié)同，抽象和復(fù)用這些本身不是微前端該解決的問題，這是綜合因素影響下的歷史背景問題。也是需要一個(gè)個(gè)資深工程師來把控和解決的核心問題，就是需要面對(duì)不同的場(chǎng)景給出不同的治理方案。

這個(gè)道理跟防沙治沙一樣，哪有那么多一蹴而就、立竿見影的好事。

三、模塊加載

模塊加載這件事情，從玉伯大佬的成名作 sea.js 開始就是一個(gè)非常值得探討的問題。在當(dāng)時(shí) jQuery 的時(shí)代里，這是一個(gè)絕對(duì)超前的項(xiàng)目，我也在實(shí)際業(yè)務(wù)中體會(huì)過在無編譯的環(huán)境下 sea.js 的便捷。

實(shí)際上，不論是微前端、低代碼、會(huì)場(chǎng)搭建等熱門話題離不開這項(xiàng)技術(shù)基礎(chǔ)。

import * from * 我們每天都在用，但最終的產(chǎn)物往往是一個(gè)自運(yùn)行的 JS Bundle，這來自于 Webpack、Vite 等編譯技術(shù)的發(fā)展。讓我們可以更好的組織項(xiàng)目結(jié)構(gòu)，以構(gòu)建更復(fù)雜的前端應(yīng)用。

模塊的概念用久了，就會(huì)自然而然的在遇到瀏覽器環(huán)境中，遇到動(dòng)態(tài)模塊加載的需求時(shí)，想到這種類似模塊加載的能力。

比如在遇到會(huì)場(chǎng)千奇百怪的個(gè)性化營(yíng)銷需求時(shí)，能否將模塊的 Props 開放出來，給到非技術(shù)人員，以更加靈活的方式讓他們?nèi)プ鲎杂山M合。

比如在低代碼平臺(tái)中，讓開發(fā)者自定義擴(kuò)展組件，動(dòng)態(tài)的將開發(fā)好的組件注冊(cè)進(jìn)低代碼平臺(tái)中，以支持更加個(gè)性的需求。

在萬物皆組件的思想影響下，把一整個(gè)完整頁面都看做一個(gè)組件也不是不可以。于是在一些團(tuán)隊(duì)中，甚至提倡所有頁面都可以搭建、搭建不了的就做一個(gè)大的頁面組件。這樣及可以減少維護(hù)運(yùn)行時(shí)的成本，又可以統(tǒng)一管控和優(yōu)化，豈不美哉。

當(dāng)這樣大一統(tǒng)的“天才方案”逐漸發(fā)展成為標(biāo)準(zhǔn)后，也一定會(huì)出現(xiàn)一些特殊場(chǎng)景無法使用，但沒關(guān)系，這些天才設(shè)計(jì)者肯定會(huì)提供一種更加天才的擴(kuò)展方案出來。比如插件，比如擴(kuò)展，比如 IF ELSE。再后來，就會(huì)有性能優(yōu)化了，而優(yōu)化的 追趕對(duì)象 就是用原來那種簡(jiǎn)單直出的方案。

有沒有發(fā)現(xiàn)，這好像是在輪回式的做著自己出的數(shù)學(xué)題，一道接一道，仿佛將 1 + 1的結(jié)論重新演化了一遍。

?

題外話，我曾經(jīng)自己實(shí)現(xiàn)過一套通過 JSON Schema 描述 React 結(jié)構(gòu)的 “庫(kù)” ，用于一個(gè)低代碼核心層的渲染。在我的實(shí)現(xiàn)過程中，我越發(fā)覺得我在做一件把 JSX 翻譯成 JS 的事情，但 JSX 或者 HTML 本身不就是一種 DSL 么。為什么一定要把它翻譯成 JSON 來傳輸呢？或者說這樣的封裝其本身有意義么？這不就是在做 PHP、.Net 直接返回帶有數(shù)據(jù)的 HTML Ajax 一樣的事情么。

?

傳統(tǒng)的瀏覽器運(yùn)行環(huán)境下要實(shí)現(xiàn)一個(gè)模塊加載器，無非是在全局掛載一個(gè)注冊(cè)器，通過 Script 插入一段新的 JS，該 JS 通過特殊的頭尾協(xié)議，將運(yùn)行時(shí)的代碼聲明成一個(gè)函數(shù)，注冊(cè)進(jìn)事先掛載好的注冊(cè)器。

但實(shí)際的實(shí)現(xiàn)場(chǎng)景往往要比這復(fù)雜的多，也有一些問題是這種非原生方式無法攻克的問題。比如全局注冊(cè)器的命名沖突；同模塊不同版本的加載沖突；并發(fā)加載下的時(shí)序問題；多次模塊加載的緩存問題 等等等等等...

到最后發(fā)現(xiàn)，這些事情好像又是在用 JS 做瀏覽器該做的事情。然而瀏覽器果然就做了，<script type="module"></script>，Vite 就主要采用這種模式實(shí)現(xiàn)了它 1 年之內(nèi)讓各大知名項(xiàng)目切換到 Vite 的壯舉。

“但我們用不了，有兼容性問題。”

哇哦，當(dāng)我看著大家隨意寫出的 display: grid 樣式定義，不禁再次感嘆人們對(duì)未知的恐懼。

import.meta 的兼容性是另外一個(gè)版本，是需要 iOS12 以上，詳情參考：https://caniuse.com/?search=import.meta

試想一下，現(xiàn)在的低代碼、會(huì)場(chǎng)搭建等等各類場(chǎng)景的模塊加載部分，如果都直接采用 ESM 的形式處理，這對(duì)于整個(gè)前端生態(tài)和開發(fā)體驗(yàn)來說會(huì)有多么大的提升。

模塊加載，時(shí)至今日，本來就已經(jīng)不再需要 loader。正如 seajs 中寫的：前端模塊化開發(fā)那點(diǎn)歷史（https://github.com/seajs/seajs/issues/588）

?

歷史不是過去，歷史正在上演。隨著 W3C 等規(guī)范、以及瀏覽器的飛速發(fā)展，前端的模塊化開發(fā)會(huì)逐步成為基礎(chǔ)設(shè)施。一切終究都會(huì)成為歷史，未來會(huì)更好。

?

結(jié)語

文章的結(jié)尾，我想感嘆另外一件事，國(guó)人為什么一定要有自己的操作系統(tǒng)？為什么一定需要參與到一些規(guī)范的制定中？

因?yàn)槲覀兊闹腔坌枰虚_花的土壤，國(guó)內(nèi)這千千萬開發(fā)者的抱負(fù)需要有地方釋放。

如果沒有自己掌握核心技術(shù)，就是只能在問題出現(xiàn)的時(shí)候用另類的方式來解決。最后在一番折騰后，發(fā)現(xiàn)更底層的技術(shù)只要稍稍一改就可以實(shí)現(xiàn)的更好。這就像三體中提到的 “智子” 一樣，不斷在影響著我們前進(jìn)的動(dòng)力和方向。

不論是小程序、微前端還是模塊加載。試想一下，如果我們有自己的互聯(lián)網(wǎng)底蘊(yùn)，能決定或者影響操作系統(tǒng)和瀏覽器的底層能力。這些 “怪啖” 要么不會(huì)出現(xiàn)，要么就是人類的科技創(chuàng)新。

?

希望未來技術(shù)人不用再追逐 Write Once, Run Everywhere 的事情...

?