Micro Frontends
Micro frontends decompose the frontend into independently deployed units — vertical slices per team or domain — composed at runtime or build time, trading bundle purity for team autonomy.
Definition
Micro frontends split a web application into separately developed and deployed pieces, each owning a vertical slice of UI. Composition happens at runtime via iframes, module federation, or server-side includes; or at build time via package composition. Shared governance covers the shell, routing, design system, and cross-cutting state. The goal is organizational: teams ship their slices without coordinating releases.
Context and scope
Adopted by large product organizations with many frontend teams: e-commerce platforms, dashboards assembling many domains. Costs are real and only pay off above team-count thresholds.
Common misconceptions
- Micro frontends make frontends faster — they usually add payload duplication and integration overhead; the win is team throughput, not page speed
- Each fragment can use any framework — technically yes, at user cost in bundle size, memory, and design coherence; consolidation pressure is real
- Runtime composition is the only true form — build-time composition delivers the autonomy with fewer runtime moving parts for many orgs
Anti-patterns
- Sharing mutable global state between fragments through window and creating invisible coupling
- Duplicating the framework and design system per fragment and shipping megabytes of redundancy
- Splitting horizontally by layer instead of vertically by domain and coupling every fragment to every release
Related concepts
Authoritative source
What it is
Backend microservices bought team independence by splitting deployment. Micro frontends buy the same independence for the browser: each team owns a slice from data to pixels and deploys it alone.
How it works
An application shell owns routing, layout, and shared runtime. Fragments register routes and render into slots — via iframes (strong isolation, weak integration), web components, or module federation (shared dependencies, better integration). Cross-fragment communication uses events or a thin shared store. A governed design system keeps visual coherence without centralizing code ownership.
When to use it
Many teams, one product surface, with integration pain that outweighs integration cost — typically dozens of frontend engineers. Below that, a modular monolith frontend with enforced boundaries is cheaper in every dimension.
Pitfalls
The shell becomes the new monolith — it needs its own governance and release discipline. Dependency duplication inflates bundles: shared singleton strategy via externals or federation matters. Deep links across fragments and cross-fragment transactions (multi-step flows) are the hard integration problems that decide the architecture fate.