Understanding Micro Frontends: Concepts, Scenarios, and Solution Comparisons

Micro frontends decompose a large front‑end application into smaller, independently developed, tested, and deployed sub‑applications that appear to users as a cohesive product. The concept is familiar to many front‑end engineers and can be implemented using various techniques such as iframes, routing proxies, or dedicated frameworks.

Typical scenarios for adopting micro frontends include:

Maintaining or refactoring legacy monolithic projects with mixed technology stacks.

Rapidly validating experimental features or A/B testing multiple implementations.

Building customizable, modular functionality for different clients or domains.

Supporting simultaneous gray‑release of multiple product features.

When planning a micro‑frontend architecture, developers must consider several technical aspects:

Communication and state management: establishing reliable messaging between parent and child apps, often via a publish‑subscribe model.

JavaScript and CSS sandboxing: preventing global variable pollution and style leakage.

Routing synchronization: preserving sub‑application URLs across page refreshes and enabling cross‑app navigation.

Pre‑loading and performance: leveraging idle time to load resources and reducing first‑load white‑screen time.

Handling shared dependencies: avoiding duplication and version conflicts.

Lifecycle management and keep‑alive support: keeping sub‑applications alive across navigation.

Support for nested sub‑applications and HTML entry points.

Popular implementation approaches include:

1. Nginx forwarding

Uses server‑side routing to compose applications but cannot address most micro‑frontend concerns such as sandboxing or state sharing.

2. Pure iframe

Provides strong isolation but suffers from communication complexity, route loss, DOM fragmentation, long white‑screen times, and lack of keep‑alive.

3. Qiankun (base‑app model)

Based on single‑spa, offers global state APIs, JS/CSS isolation (with some sandbox issues), pre‑loading, and lifecycle hooks, but does not support multiple active sub‑apps with routing and lacks keep‑alive.

4. micro‑app

Uses web components and HTML entry, supports keep‑alive and nesting, communicates via custom events, but still has limitations in shared dependency handling and routing control.

5. Module Federation

Shares dependencies at build time, but provides no sandbox, limited CSS isolation, no built‑in communication, and lacks HTML entry, keep‑alive, and comprehensive routing management.

6. wujie

Combines iframe with web components, offering three communication methods (props, window, eventBus), solves iframe routing and DOM fragmentation by proxying the document to a ShadowRoot, reduces first‑load white‑screen via pre‑instantiation, supports idle‑time pre‑loading, and provides route synchronization, cross‑app navigation, keep‑alive, and graceful degradation for browsers without web‑component support.

In summary, the article emphasizes that successful micro‑frontend adoption requires careful attention to code management, independent build pipelines, elegant integration, appropriate scenario selection, and extensibility, while acknowledging trade‑offs in security, data integrity, and UI consistency.