React micro-frontends with Webpack Module Federation

Large product surfaces are rarely one frontend anymore. Checkout, dashboards, settings, and the chrome around them often belong to different squads, each with its own backlog, debt, and ship calendar. That shape is usually called micro-frontends: independently owned UI slices that still present as one product, the client-side analogue of microservices.

For a long time the React tooling for that pattern was awkward. Organizations either kept a single giant SPA bundle or embedded separate apps in iframes and accepted the costs. Webpack 5’s Module Federation made a third path practical: independently built and deployed JavaScript apps that compose at runtime in one browser document. Understanding what that feature does—and why it displaced the older workarounds—matters for anyone designing multi-team React systems.

The Problem Before Module Federation

Before Federation shipped, teams that wanted independent frontend delivery had limited choices.

The default was the monolithic SPA: one repository, one pipeline, one deploy. That model is fine for a small group. As ownership spreads, friction grows. Every feature shares one build. Compile times climb with the codebase. A regression in one area can freeze another team’s release train. Aligning deploys across many groups becomes project management of its own.

Iframes were the other widespread escape hatch. Embedding a complete child application inside a parent page gave true deploy independence, which is why so many enterprises used them. The trade-offs stacked up quickly:

• Isolation is absolute. Styles, DOM, and JavaScript contexts do not mix. Sharing state, coordinating data, or enforcing one design language across parent and child becomes hard engineering instead of ordinary prop passing.
• Dependencies duplicate. Each frame often loads its own React, shared libraries, and CSS. Users download the same bytes repeatedly.
• UX edges fray. Scroll, focus, resize, deep links, and history across frame boundaries need custom glue and still feel wrong.
• SEO and accessibility suffer. Content in frames is harder to index and less consistent for assistive technology.
• Communication is message-only. Cross-frame data means postMessage and hand-rolled protocols—no shared memory, no shared React context.

Iframes solved ship independently and created a worse integrate cleanly problem. What was missing was build- and deploy-time independence without abandoning a single-document user experience.

What Is Module Federation?

Module Federation, introduced with Webpack 5, lets separately built and deployed JavaScript applications share code at runtime rather than at compile time.

In practice you can run several apps—from different teams, pipelines, and release trains—that still assemble in the browser as one product. One application exposes a component, route, or helper; another consumes it as if it lived in the same package, without rebuilding the consumer when the provider changes.

That runtime composition is the usual technical base for React micro-frontends today.

How It Works: Hosts, Remotes, and Shared Dependencies

Federation names two roles:

• A host loads code published elsewhere. It is often the shell that mounts other teams’ UI.
• A remote publishes modules for others: pages, components, hooks, or utilities.

One app can be both: expose some modules while consuming others.

Remotes declare exports in Webpack config; hosts declare which remotes to load and which symbols to import. Loading happens in the browser against a remote entry URL. The host build does not need the remote’s source—only a stable entrypoint it can fetch when the app runs.

Shared dependencies complete the picture. When host and remote both need React, Federation can be told to share one React instance instead of shipping two. That removes the iframe-style duplication while still allowing teams to diverge on versions when they must.

Module Federation vs. Iframes

The comparison is why so many teams left iframes once Federation matured. You keep the deploy independence that made frames attractive, without surrendering integration quality. Remotes paint into the host DOM, share one JavaScript world, and can reuse providers, state, and design-system packages—work that was painful or impossible across an iframe boundary.

Why Big Teams Use It

Small products rarely need this machinery. Organizations with many frontend teams on one surface use Federation to fix structural bottlenecks:

• Independent deploys. A remote can ship a fix without rebuilding every other team’s artifact.
• Team autonomy. Each group keeps its own cadence, CI, and, within limits, tooling choices.
• Faster builds. Separate remotes mean a small change does not rebuild a monolith.
• Incremental modernization. Legacy shells can grow new remotes piece by piece instead of a single cutover.
• Stack flexibility. Sharing a framework is easiest, but teams sometimes bridge major versions—or, with more effort, different frameworks—through Federation boundaries.

Real-World Use Cases

Commerce sites often let catalog, checkout, and account teams own separate remotes. SaaS products ship dashboard widgets or settings panels from feature teams without opening the core shell for every change. Migrations peel slices off a legacy SPA into remotes while the old surface still runs.

Key Benefits Recap

Federation’s value is a short list: real independent deployability, a shared runtime that avoids duplicated libraries and brittle cross-app messaging, and a user experience that still feels like one application. It delivers the autonomy iframes promised without the integration and performance tax.

Conclusion

Moving from iframes to Module Federation is part of a wider maturity in frontend architecture: deploy independence and a coherent UX no longer have to be opposites. Webpack 5 made that combination workable for React-heavy organizations that had outgrown a single bundle. As adoption grows and tools such as Rspack and Module Federation 2.0 extend the same runtime-sharing ideas, knowing why the shift happened helps anyone designing large React systems choose ownership boundaries deliberately instead of defaulting to frames or to an ever-growing monolith.

Try It Yourself

A minimal host/remote sample is available at react_module_federation.

Clone it locally:

git clone https://github.com/ModithaM/react_module_federation.git
cd react_module_federation

Start the remote first so its exposed entry is serving before the host asks for modules:

cd remote
npm install
npm start

In a second terminal, start the host:

cd host
npm install
npm start

Open the host in the browser; it should load remote components at runtime and demonstrate the relationship described above. Order matters: a host started alone has nothing to fetch until the remote is up, which is a useful reminder that Federation’s independence still depends on remotes being reachable when the shell boots.