本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 框架和工具
<a name="frameworks-tools"></a>

不乏前端框架，例如 Angular 和 Next.js，但其中大多數都不是考慮到微前端的創建。因此，它們有時會缺少解決微型前端架構挑戰的機制。

## 一般框架考量
<a name="framework-general"></a>

本指南並不旨在推薦或比較個別框架。由於多個微前端通常在同一個 Web 應用程序頁面上運行，因此加載和運行時性能是主要考慮的問題。選擇一個引入盡可能少開銷的框架非常重要。

框架根據渲染層進行劃分：
+ 用戶端轉譯 (CSR)
+ 伺服器端渲染 (SSR)

前端架構包括其他功能，例如靜態網站產生 (SSG)。不過，SSG 只會執行一次。微前端主要是在運行時組成，因此 CSR 和 SSR 是主要選項。

**用戶端渲染**

對於 CSR，有兩個熱門選項：
+ 單水療中心框架
+ 模塊聯合

單 SPA 是構成微型前端的輕量級選擇。它解決了微型前端架構中最常見的挑戰，例如在同一頁面中撰寫多個微前端，以及避免相依性衝突。

模塊聯合會開始作為一個插件，由 webpack 5 提供，它解決了微前端體系結構中的絕大多數挑戰，包括跨不同工件的依賴關係管理。模塊聯合 2.0 本地與 Rspack，webpack，電子版本地工作，現在使用. JavaScript 

考慮根本不使用框架。根據 [caniuse.com](https://caniuse.com/usage-table) 的說法，現代瀏覽器的整體市場份額為 98％，本地提供了諸如自定義元素之類的功能，並且它們足以用於微型前端應用程序。必要時，請將自訂元素與輕量型程式庫結合在一起，以進行事件傳播、國際化或其他特定問題。

**伺服器端渲**

在 SSR 方面，兩個主要選項比較複雜：
+ 擁抱現有的框架，例如 Next.js，並應用使用模塊聯合的微前端原則。
+ 使用 HTML-交over-the-wire 換代表微前端的 HTML 片段，並在執行階段在範本中撰寫這些片段。這種方法的一個例子是講台。