微前端的核心價值
整理自11.20晚阿里雲微前端線下沙龍
整個會議下來，我只對一個話題有興趣，就是#大果提出的靈魂拷問：
如果是widget 級別，那麼微前端跟業務組件的區別在哪裡？微前端到底是因何而生？
圓桌環節簡單發表了一下自己的觀點，這裡再文字補充一下：
先拋觀點：
我認為微前端的核心價值在於"技術棧無關"，這才是它誕生的理由，或者說這才是能說服我採用微前端方案的理由。
為什麼"技術棧無關"這麼重要？
我拋兩個場景，大家思考一下：
- 你新入職一家公司，老闆扔給你一個5 年陳的項目，需要你在這個項目上持續迭代加功能。
- 你們起了一個新項目，老闆看慣了前端的風起雲湧技術更迭，只給了架構上一個要求："如何確保這套技術方案在3~5 年內還葆有生命力，不會在3、5 年後變成又一個遺產項目？"
第一個場景我們初步一想，可以啊，我只需要把新功能用react/vue 開發，反正他們都只是ui library，給我一個dom 節點我想怎麼渲染怎麼渲染。但是你有沒有考慮過這只是浮在表層的視圖實現，沉在底下的工程設施呢？我要怎麼把這個用react 寫的組件打出一個包，並且集成到原來的用es5 寫的代碼裡面？或者我怎麼讓webpack 跟之前的grunt 能和諧共存一起友好的產出一個符合預期的bundle？
第二個場景，你如何確保技術棧在3~5 年都葆有生命力？別說跨框架了，就算都是react，15 跟16 都是不兼容的，hooks 還不能用於class component 呢我說什麼了？還有打包方案，現在還好都默認webpack，那webpack 版本升級呢，每次都跟進嗎？別忘了還有babel、less、typescript 諸如此類呢？別說3 年，有幾個人敢保證自己的項目一年後把所有依賴包升級到最新還能跑起來？
為什麼舉這兩個場景呢，因為我們去統計一下業界關於”微前端“發過聲的公司，會發現adopt 微前端的公司，基本上都是做ToB 軟件服務的，沒有哪家ToC 公司會有微前端的訴求（有也是內部的中後台系統），為什麼會這樣？很簡單，因為很少有ToC 軟件活得過3 年以上的。而對於ToB 應用而言，3~5 年太常見了好嗎！去看看阿里雲最早的那些產品的控制台，去看看那些電信軟件、銀行軟件，哪個不是10 年+ 的壽命？企業軟件的升級有多痛這個我就不多說了。所以大部分企業應用都會有一個核心的訴求，就是如何確保我的遺產代碼能平滑的遷移，以及如何確保我在若干年後還能用上時下熱門的技術棧？
不論是qiankun /OneX(螞蟻基於qiankun打造的雲應用接入平台)最開始誕生的初衷，還是後續在於社區的交流過程中都發現，如何給遺產項目續命，才是我們對微前端最開始的訴求。阿里的同學們可能感受不深，畢竟那些一年掙不了幾百萬，沒什麼價值的項目要么是自己死掉了，要么是扔給外包團隊維護了，但是要知道，對很多做ToB 領域的中小企業而言，這樣的系統可能是他們安身立命之本，不是能說扔就扔的，他們承擔不了那麼高的試錯成本。
我認可的解決思路應該是，撒旦的歸撒旦，耶穌的歸耶穌。
我們只需要在主系統構造一個足夠輕量的基座，然後讓各子應用按照共同的協議去實現即可。這個協議可以包括，主應用應該如何加載子應用，以及子應用如何被主應用感知、調度，應用之間如何通信等。這個協議不應該包括，子應用要如何確保隔離性、安全性，也就是子應用除了實現一些較為簡單的協議之外，跟開發一個正常的spa 應用應該沒有任何差別，包括不應該有開發、構建、發布等流程上的侵入。只要子應用實現了這幾個協議，其他的東西怎麼玩，我們都不需要關心或乾預。
這樣的話，其實整個系統就變成了一個真正的、基於運行時的插件平台了。
有一個非常合適的例子，我們通常是怎麼看待可視化搭建平台的？我想大部分pro code 玩家都是不太敢輕易嘗試這個方式去開發自己的核心產品的，原因是什麼呢？很簡單，不可控。我的產品的上限由平台決定而不是我自己的coding 能力決定，這就很要命了。尤其是一些核心模塊，後面我想做一些個性性的改造可能都支持不了。但是如果有了微前端機制呢，只需要搭建平台去實現相關的協議，平台產出的頁面就能很輕易的被集成到我們自己的應用裡了。我們開發時可以選擇需要強控制的頁面自己寫，邊緣頁面用可視化生成即可，完全沒有任何心理負擔。
為什麼我認為"技術棧無關"才是微前端的初衷？
我們聽到了很多不同團隊的分享中，關於微前端帶來的各種業務提升、產品提升的價值。比如產品的自由組合能力，比如以widget 這種可視化方式直接輸出產品的能力等等，將這些價值視作微前端誕生的理由。
但我對此一直保持的觀點是，微前端首先解決的，是如何解構巨石應用，從而解決巨石應用隨著技術更迭、產品升級、人員流動帶來的工程上的問題。解構之後還需要再重組，重組的過程中我們就會碰到各種隔離性、依賴去重、通信、應用編排等問題。在解決了這些問題之後，才是產品的自由組合、widget 輸出等能力。同時由於有了前者能力的鋪墊和加持，這些產品上的價值提升也就變得很自然和容易。
不論是OneX還是阿里雲的同學，都在反復強調微前端帶來的業務價值及產品價值，比如產品的組合能力，widget的產品輸出能力（這些能力在我們的產品域確實很重要也很有價值，但並不是所有的控制台產品都一定需要的能力）。從分享中我們也能看到，雲產品對於微前端的訴求是基本相同的，包括背後的管控、編碼能力等。但我們需要清楚一件事，並不是只有云產品才需要微前端，也並不是所有採用微前端方案的公司都是做雲產品的。
大果提的問題非常我認為有探討價值：「widget 級別的微前端應用跟業務組件有什麼區別？」
我的觀點：有沒有區別在於你的實現是不是技術棧無關。
以大果提到的淘寶吊頂js 為例（這是一個非常貼切的舉例，螞蟻也有類似的js 組件），它具備獨立發布、固定地址自動升級等特點，我猜也不會限制調用方的技術棧，調用方使用時跟用一個普通的library一樣，區別在於普通的library是通過npm包引入，但是這個library我們是通過script標籤引入的。
但是考察是否技術棧無關不能簡單看這些api 設計，還要看是否存在一些隱性耦合。
比如是否要求調用方的react 版本、是否要求調用方必須提前構造好一些上下文環境才能完成調用。
如果這些回答都是否，那麼我認為這也是一種微前端的實現方式。
克軍提到：
如果微前端只存在工程上的價值是不值得大張旗鼓去做的。
微前端的初衷應該還是來解決工程問題的，帶來的產品價值在不同的領域可大可小。比如在阿里雲這種典型的雲產品控制台的場景下，它帶來的產品價值就會很可觀。因為阿里云作為提供IAAS 服務的雲平台，它需要的就是平台、產品的被集成能力，在這種場景下，微前端能力能非常好的契合這個訴求。但需要強調的是，並不是所有採用微前端的客戶，都是阿里雲這種IAAS 平台產品。很多中小型控制台大多沒有產品自由組合能力的訴求。產品能力只能算是微前端的能力的一種延伸。
玉伯提到：
今天看各BU 的業務問題，微前端的前提，還是得有主體應用，然後才有微組件或微應用，解決的是可控體系下的前端協同開發問題（含空間分離帶來的協作和時間延續帶來的升級維護）
總結的很精確。 「空間分離帶來的協作問題」是在一個規模可觀的應用的場景下會明顯出現的問題，而「時間延續帶來的升級維護」幾乎是所有年齡超過3 年的web 應用都會存在的問題。
微前端方案正確的架構姿勢
既然「技術棧無關」是微前端的核心價值，那麼整個架構方案的實現上，都應該秉持這一原則，任何違背這一原則的做法都應該被摒棄。
「技術棧無關」是架構上的準繩，具體到實現時，對應的就是：應用之間不應該有任何直接或間接的技術棧、依賴、以及實現上的耦合。
比如我們不能要求子應用、主應用必須使用某一版本的技術棧實現。
比如在通信機制的設計與選擇上，盡量基於瀏覽器原生的CustomEvent api，而不是自己搞的pub/sub。
比如子應用是否具備不依賴宿主環境獨立運行的能力，衡量標準是是否能一行代碼不改，或者只改很少的配置，就能達成這一目標。
所以我認為正確的微前端方案的目標應該是：方案上跟使用iframe 做微前端一樣簡單，同時又解決了iframe 帶來的各種體驗上的問題。
理想狀態下，以此為目標的微前端應用，是自動具備流通能力的，且這個流通能力不會因為主應用的實現升級而喪失（也就是說在19 年能接入主應用的微前端應用，到了2025 年也應該能正常接入正常運行，並同樣保有在不同主應用間流通的能力）。
qiankun正是以此為準則設計的。
如果說阿里的企業使命是：「讓天下沒有難做的生意」。
那麼微前端的使命我認為是：「讓天下沒有短命的控制台」。
事實上如果所有的web技術棧能做到統一，所有library的升級都能做到向下兼容，我們確實就不需要微前端了。 —— 魯迅
招聘
最後打個招聘廣告，螞蟻金服體驗技術部招聘前端啦！要求P6 及以上！有興趣的同學可以發簡歷到