Micro-frontends extend microservice architecture to the frontend. Instead of one large application, independent teams build, test, and deploy UI modules separately. But the complexity cost is significant.
Architecture Comparison
| Factor | Monolithic Frontend | Micro-Frontends |
|---|---|---|
| Codebase | Single repository | Multiple repositories/packages |
| Deployment | One build, one deploy | Independent deployments per module |
| Team structure | One frontend team | Multiple autonomous teams |
| Technology freedom | One framework | Mix frameworks (risky) |
| Build time | Grows with codebase | Per-module (smaller, faster) |
| Bundle size | Optimized (single build) | Potential duplication |
| Shared dependencies | Naturally shared | Module Federation / import maps |
| State management | Global state available | Cross-module state is complex |
| Routing | Single router | Composed routing |
| Styling | Global + scoped | Strictly scoped (isolation required) |
| Testing | Standard E2E | Contract testing + E2E |
| Debug complexity | Standard | Multi-module debugging |
| Performance | Generally better | Overhead from runtime composition |
| Onboarding | Learn one codebase | Learn architecture + modules |
| Consistency | Natural (shared components) | Requires design system enforcement |
When Micro-Frontends Make Sense
- 10+ frontend developers: Multiple teams stepping on each other
- Large organizations: Teams own specific product areas (checkout, search, profile)
- Independent release cycles: Different teams deploy at different cadences
- Legacy modernization: Strangler pattern around legacy frontend
- Acquisitions: Integrating purchased products into a larger platform
When Monolithic Frontend Is Better
- Teams under 10 developers: Overhead outweighs benefits
- Startups: Speed and simplicity matter most
- Consistent UX: One design, one implementation
- Performance-critical: No runtime composition overhead
- Most applications: Monolith handles 90%+ of use cases
Implementation Approaches
| Approach | Complexity | Performance |
|---|---|---|
| Module Federation (Webpack/rspack) | High | Good |
| Import maps | Medium | Good |
| Web Components | Medium | Moderate |
| iframes | Low | Poor (isolation trade-off) |
| Server-side composition | Medium | Good |
| Build-time composition (monorepo) | Low | Best |
Warning Signs You Need Micro-Frontends
- Deploy queue exceeds 2 weeks because teams block each other
- Teams wait days for code review from other teams' areas
- A change in one area regularly breaks another area
- Different teams genuinely need different technology choices
- The application serves fundamentally different user personas
Our Recommendation
For nearly every project we build, a monolithic frontend (often in a monorepo with shared packages) is the right choice. The complexity tax of micro-frontends only pays off at organizational scales most businesses never reach. If you have 3-8 frontend developers, a well-structured monorepo with Turborepo gives you code ownership, fast builds, and shared components without micro-frontend overhead.
Architect your frontend with the right structure for your scale.