Micro-frontends in Practice: Benefits and Pitfalls

Micro-frontends bring the microservices idea to the UI: split a large web application into pieces that separate teams develop, deploy and run on their own. In October 2026 the main tool is Module Federation 2.0, stable since 10 February 2026, while single-spa is still on version 6.0.3 from September 2024. The pattern pays off when four or more teams block each other in the same application; below that, a monorepo gives you almost the same with fewer moving parts. This guide covers the current options, the problems that show up in production and a test for deciding against them. It is also available in Spanish.

Key takeaways

• The signal to consider micro-frontends is organisational: four or more teams that need to ship at their own pace and block each other today in the same repository or deployment pipeline.
• Module Federation 2.0 adds to Webpack 5’s Module Federation a bundler-independent runtime, a manifest, remote types and debugging tools; it works with Webpack, Rspack and Vite.
• single-spa is still a valid orchestrator for mixing frameworks, but its latest stable release is from September 2024 and 7.0 has been in beta since 2025.
• The costs that weigh most in production are shared dependency versions, leaking CSS, shared state and end-to-end testing.
• If you have one team, a small product or a backend bottleneck, do not use them: a monorepo with module boundaries solves the problem at a lower cost.

When do micro-frontends make sense?

Micro-frontends make sense when the problem is coordination between teams, not technology. The typical case is four or five product teams contributing to the same single-page application (SPA) and waiting on each other to release. Cam Jackson’s reference article on martinfowler.com^[1] frames the goal in those terms: autonomous teams with independent deployments.

There are three scenarios where the cost is recovered:

• Separate functional domains: a shop with catalogue, checkout and user account, each with its own team and pace.
• Independent release cycles: teams that need to deploy more than once a day without waiting for everyone else’s window.
• Progressive migration: wrapping a legacy application with new pieces and retiring the old one in parts, instead of rewriting it in one go.

What are the options in 2026?

In October 2026 there are four ways to compose micro-frontends, and Module Federation is where the activity is. We checked the version data in this section against the npm registry on 27 October 2026.

iframes

The iframe gives the most isolation: each piece lives in its own document and talks through postMessage. That isolation is also its limit, because navigation, accessibility, content sizing and search engine visibility all have to be solved by hand. It suits embedding internal legacy tools, not a seamless user experience.

Module Federation 2.0

Module Federation was born in Webpack 5, released in October 2020, and lets one application load at runtime modules compiled by another and share dependencies such as React. Version 2.0 was announced in April 2024 and has been stable since 10 February 2026. According to its official documentation^[2], it decouples the runtime from the bundler and adds a manifest (mf-manifest.json), types for remote modules, runtime plugins and a Chrome extension for debugging.

The practical change is that it is no longer tied to Webpack. The same setup works with Rspack, Rsbuild and Vite (through @module-federation/vite), and there are integrations for Next.js, Modern.js and Angular. The stable 2.0 release also added tree shaking of shared dependencies, which cuts the weight each remote carries.

single-spa

single-spa^[3] works as an application router: it mounts and unmounts micro-frontends based on the URL and lets you mix React, Vue and Angular on the same page. It is still a valid choice for that case, but its pace has slowed. The latest stable release is 6.0.3, from September 2024, and the 7.0 branch is in beta (7.0.0-beta.13, from September 2025).

Native Federation and import maps

Native Federation brings the Module Federation model to standard ES modules and browser import maps, without depending on a specific bundler. Import maps work in Chrome and Edge from version 89, Firefox from 108 and Safari from 16.4, according to MDN’s compatibility data^[4]. It is the route the Angular ecosystem promotes with @angular-architects/native-federation.

The problems that show up in production

Micro-frontends move complexity from the organisation to runtime, and that complexity shows up in six places:

• Dependency versions: if two teams load incompatible versions of React, you get failures that do not reproduce locally. You need a shared version policy or you accept duplicated packages.
• Leaking CSS: one piece’s global styles affect the others. CSS Modules, CSS-in-JS or Shadow DOM prevent it, each at its own cost.
• Shared state: passing data between pieces without coupling them takes an event bus, custom DOM events or a shared service, and none of them comes free.
• Performance: each piece brings its own JavaScript bundle; without well-configured shared dependencies, the page downloads one copy of the same libraries per piece.
• End-to-end testing: each piece’s tests pass and the composition fails. You need a pipeline that tests the whole page.
• Visual consistency: without a common design system, each team drifts and the page looks stitched together from scraps.

Module Federation 2.0 tackles part of these costs. Its manifest and runtime plugins let you retry or replace a remote that fails to load, and multiple share scopes isolate versions of a dependency. The other difficulties are organisational and no tool solves them.

When should you not use micro-frontends?

Do not use micro-frontends if any of these conditions holds, because the cost of runtime composition will exceed the cost of coordinating people:

1. There is a single frontend team, or two that coordinate without friction.
2. The product is small or young and its domain boundaries still change every few months.
3. The bottleneck is in the backend, in design or in the deployment pipeline, not in the UI code.
4. There is no versioned design system and no team to maintain the composition platform.
5. What you want is to mix frameworks out of preference, not for a migration with an end date.

If the answer to all of them is no, settle five requirements first:

• A design system with components published as packages
• Versioning rules enforced in continuous integration
• A pipeline that tests the whole page
• Observability that correlates errors per page
• A platform team, the role the guide on platform engineering and internal developer platforms describes

For observability, the Grafana stack with Loki, Tempo and Mimir lets you follow an error across the pieces of one page.

Cheaper alternatives

Before the full pattern there are three intermediate options that give a good part of the organisational benefit:

• Monorepo with module boundaries: Nx or Turborepo give you per-project builds and tests with a single deployment, and dependency rules stop one team from importing another team’s internal code.
• Component packages: each team publishes its part as a versioned internal library and a single SPA consumes them.
• Logical boundaries in the code: bounded contexts inside the same application, the frontend equivalent of the modular monolith compared in the guide on modules vs. microservices.

All three keep a single deployable artefact, so there are no versions to negotiate at runtime. The shared design system is still needed, and a design system in Figma managed as the single source helps in every case.

Frequently asked questions

What is Module Federation 2.0 and how does it differ from Webpack 5’s?

It is the evolution of the Module Federation that Webpack 5 shipped in 2020. It keeps remote module loading and dependency sharing, and adds a bundler-independent runtime, a manifest, types for remotes, runtime plugins and a Chrome extension. It works with Webpack, Rspack and Vite, and has been stable since 10 February 2026.

Is single-spa still maintained?

Yes, but with less activity than Module Federation. The latest stable release is 6.0.3, from September 2024, and 7.0 has been in beta since 2025. For orchestrating applications built with different frameworks by route it still works; for sharing dependencies between pieces, Module Federation is today the option with the most development.

How many teams do you need for micro-frontends to pay off?

There is no official figure, but the pattern starts to pay off with four or five teams that block each other in the same application and need to release separately. With one or two teams, a monorepo with module boundaries gives almost all the benefit without the complexity of composing the page at runtime.

Conclusion

Micro-frontends are a legitimate tool for large organisations with a real frontend coordination problem, and in 2026 Module Federation 2.0 is their most active foundation. They are not an architectural improvement in themselves: they move complexity from the organisation to runtime. They pay off only when the cost of coordinating people exceeds that added complexity; in every other case, start with a well-bounded monorepo.

Sources: [1] Cam Jackson, Micro Frontends, on martinfowler.com^[1], [2] Module Federation, official documentation^[2], [3] Module Federation 2.0 Stable Release^[5], [4] single-spa, getting started guide^[3], [5] Import maps on MDN^[4].

Sources

1. martinfowler.com
2. official documentation
3. single-spa
4. MDN’s compatibility data
5. Module Federation 2.0 Stable Release