Micro frontends are an architectural style where independently developed and deployed frontend applications are combined into a single user experience. Think of them as microservices for the UI: instead of one large frontend maintained by many teams, the system is divided into smaller apps owned by separate teams.
Why companies adopt micro frontends
- Independent deployments — teams release features without waiting on one shared deployment.
- Team autonomy — each team owns a business slice (payments, dashboard, auth, analytics) end to end.
- Faster development at scale — multiple teams work in parallel without constantly blocking each other.
- Technology flexibility — teams can adopt frameworks or versions gradually, without rewriting the whole app.
- Easier modernization — legacy areas can be migrated piece by piece instead of one risky big-bang rewrite.
Common implementation approaches
- Module Federation (Webpack / Vite) — share and load remote modules at runtime.
- Web Components — framework-agnostic custom elements as the integration layer.
- Server-side composition — assemble the final page on the server.
- Client-side composition — combine applications in the browser.
- iframes — the strongest isolation between apps, at the cost of UX friction.
Challenges you should know
- Increased complexity — architecture, routing, state management and communication become harder.
- Performance risks — multiple bundles and duplicated dependencies can increase page size.
- Design consistency — without a strong design system, apps may look and behave differently.
- Shared state management — communication between micro frontends requires clear contracts.
- Harder debugging — problems can span multiple applications, repositories and teams.
When micro frontends make sense
Large enterprise applications, multiple independent teams, complex business domains, frequent deployments, and long-term product growth.
When they are overkill
Small teams, startups building an MVP, projects with one to three developers, and applications with simple business logic.
Key takeaway: micro frontends are not a default. Start with a monolith and adopt micro frontends only when organizational growth creates bottlenecks a monolith can no longer handle.