Native Federation vs Module Federation for Angular Micro-Frontends

Most Angular teams that went micro-frontend before 2023 did it with Webpack Module Federation. It worked, but it tied you to Webpack — which became an awkward fit once Angular's default builder moved to esbuild and Vite. Native Federation solves the same problem using native ESM and import maps instead of a Webpack-specific runtime, so it works with any build tool.

The core idea is unchanged

Both approaches solve the same problem: let independently built and deployed applications share code and compose at runtime, without a shared build step. A host shell loads remotes — other Angular applications — on demand, and they share singletons like @angular/core so you're not shipping Angular five times over.

Where they actually differ

• Build tool coupling. Module Federation is a Webpack plugin. Native Federation is build-tool agnostic — it works with esbuild, Vite, or Webpack, which matters once your host app has moved to Angular's esbuild-based application builder.
• Runtime mechanism. Module Federation ships a custom runtime and container format. Native Federation uses the browser's own <script type="importmap"> and dynamic import(), so there's less custom machinery to reason about when something goes wrong.
• Shared dependency resolution. Both let you mark packages as shared singletons, but Native Federation's manifest-driven approach makes version mismatches easier to spot at build time rather than as a runtime console warning.

What this means in practice

If you're starting a new Angular micro-frontend platform today, Native Federation is the straightforward choice — it's what the Angular Architects team (who built both) now recommend, and it keeps you on Angular's native build tooling instead of pinning your platform to Webpack. If you've already got Module Federation in production, the migration is mechanical enough that it's worth planning as a dedicated piece of work rather than a side effect of some other upgrade.

The part that doesn't change either way: the hard problems are still a shared design system, consistent routing across remotes, and agreeing on what "shared" actually means across teams — the federation mechanism is the easy 20%.