上週推特爆炸性地爆發了關於“微前端”的討論，強烈的爭論和強烈的意見在雙方都有所突破。我認為就像JS中的CSS一樣，根據您的專案和組織約束，存在真正的權衡和差異。實施微型企業也有很好的方法和糟糕的方法。

首先，微前端究竟是什麼？

“微前端架構”是一種構建以微服務為模型的前端應用程式的方法。將您的前端拆分為一組可獨立部署的，鬆散耦合的應用程式。然後將這些應用程式組裝在一起以建立單個面向使用者的應用程式。

這樣做的技術方法各不相同，不同的公司做不同的事情，從伺服器端轉換到iframe到JavaScript元框架和Web元件。

優點

與微服務非常相似，微前端的擁護者強調了減少跨團隊依賴性的組織優勢。好處包括：

• 單獨部署單獨的服務
• 自主團隊獨立迭代和創新的能力
• 能夠圍繞業務部門或產品組織團隊

所有這些都是有效的好處，特別是對於大型和複雜的專案，但即使是較小的應用程式也可以從獨立部署等方面獲益。

當我在2010年開始使用電子商務應用程式（微服務前）時，我一直擔心由於無關的變化而以某種方式破壞結賬。我們建立了廣泛的測試框架來防止這種情況，但回想起來，孤立服務+微前端對於這種情況來說是完美的。

壞：操作複雜性

當我們從編輯靜態檔案到複雜的構建系統以及大型框架時，獲得正常執行的前端環境的複雜性已經大大增加。微前端進一步加劇了這種趨勢，現在在整個應用程式中進行任何型別的測試可能需要多個協調的前端，更不用說用於將它們拼接在一起的任何工具。

微服務的挑戰同樣適合微前端：

• 需要在開發中執行許多不同的應用程式來測試完整的體驗
• 跟蹤和除錯整個系統的問題
• 處理整個系統的版本控制

基本上，我們在單個前端中簡化整個系統的複雜性。

醜：效能，不一致的體驗

下面是看起來很糟糕的問題：

• 每個團隊都有自己的技術選擇，瀏覽器最終可能會下載多個框架並重復程式碼
• 使用者不會孤立地體驗您的公司或產品。這是反對完全確定元件範圍的論據之一 - 對於完全分離的團隊，問題可能更糟。
• 微前端的一些實現（特別是嵌入iframe）可能會導致巨大的可訪問性挑戰。

雖然倡導者會說，這些不具備的情況發生，這種做法似乎並使其更容易，我們會看到這些問題。

妥協：微前端體驗的範圍

這些優點或缺點如何取決於您和您的情況。對於一個小型的、共同的團隊和相對簡單的產品，微前端壞處大於好處，而對於大型多方面產品和多個分散式團隊，其好處可能開始超過挑戰。

還有一系列方法可以在沒有所有缺點的情況下獲得許多好處。

通過堅持單一框架選擇並利用像Single-spa.js這樣的協調框架，您可以通過共享資源和僅下載一次公共程式碼來減輕大部分效能損失。

使用共享元件庫，您可以消除許多使用者體驗不一致問題。

當然，在每一步中你都會放棄一定程度的獨立性。在某些時候，您根本不再擁有微前端架構。對您有意義的切入點取決於您的產品和組織。

這有點重要 - 工程學就是權衡，而微前端為你提供了另一個可以進行權衡的維度。