0Pricing
HTML Academy · Lesson

Module Federation Basics

Understand how module federation enables micro-frontend sharing.

Module Federation Basics is a free HTML Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the HTML Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What is Module Federation?

Module Federation lets a JavaScript application load and execute code from another independently deployed application at runtime. Originating in Webpack 5, the pattern is now also possible via native import maps and dynamic import.

The Use Case

Large organizations split monoliths into multiple "micro-frontends" deployed independently — a shell host plus several feature applications. Module federation lets the shell load each feature on demand without bundling them together at build time.

Webpack Federation

In Webpack 5, the host declares remotes (other apps to consume) and remotes declare exposes (what they offer). The runtime fetches a tiny manifest from each remote at startup and downloads chunks as the host imports them.

Native Equivalents

Without Webpack, the same idea works with import maps pointing to remote ESM bundles and dynamic import for loading. The host's import map says "feature-cart": "https://cart-team.example.com/entry.js"; import("feature-cart") loads the latest deployed version.

<script type="importmap">
{
  "imports": {
    "feature-cart": "https://cart.example.com/v1/entry.js",
    "feature-checkout": "https://checkout.example.com/v2/entry.js"
  }
}
</script>

Shared Dependencies

Without coordination, each remote would ship its own copy of React. Federation tools allow declaring shared dependencies — the first remote to load React makes it available to all others. Native approaches use import maps to point every remote at the same React URL.

Independent Deployment

Each team owns its remote and deploys whenever they like. The host never rebuilds; it picks up new versions on next page load (or via cache busting). This decouples release cycles entirely.

Versioning Strategies

Pin remotes to versioned URLs (/v1/entry.js, /v2/entry.js) so a host upgrade is intentional rather than implicit. Some teams use semver matching at the import map level via tools like JSPM.

Trade-offs

Federation adds runtime complexity: more network requests, harder debugging across origins, and the risk of incompatible shared dependencies. Use it when you genuinely need independent deployment; for smaller projects a single build is simpler and faster.

Error Isolation

One remote crashing should not bring down the host. Wrap dynamic imports in error boundaries (React) or try/catch (vanilla) and render fallback UI when a remote fails. The shell remains functional even if a feature is temporarily broken.

Type Safety

Remote exports have no compile-time type information in the host. Generate shared TypeScript types in a separate package consumed by both sides, or use runtime validation (Zod, io-ts) at the federation boundary.

Native vs Tooling

Native federation (import maps + ESM) is simpler and standards-based but lacks Webpack's shared-dep coordination. Choose Webpack/Module Federation for complex apps with heavy shared dependencies; choose native for simpler micro-frontend setups.

Future Direction

The W3C is exploring richer module loading primitives that would make native federation more capable — including better shared-dependency negotiation. Today, treat import maps as the foundation and layer your federation tooling on top.

Knowledge Check

What is the primary motivation for using Module Federation in a large application?

Summary

Module Federation lets a host load code from independently deployed remotes at runtime. Webpack 5's tooling adds shared-dependency negotiation; native federation uses import maps and dynamic import. Use for micro-frontend architectures with multiple teams; accept the added complexity in exchange for independent deployment freedom.

Frequently asked questions

Is the “Module Federation Basics” lesson free?

Yes — the full text of “Module Federation Basics” is free to read here on the web, and the HTML Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the HTML Academy course, upgrade to CoddyKit PRO.

What will I learn in “Module Federation Basics”?

Understand how module federation enables micro-frontend sharing. You practise HTML Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start HTML Academy?

No prior experience is required. HTML Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Module Federation Basics” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this HTML Academy lesson?

Yes. Every HTML Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. ES Module Scripts type=module
  2. Import Maps importmap
  3. Dynamic Import() in Modules
  4. Module Federation Basics
← Back to HTML Academy