> ## Documentation Index
> Fetch the complete documentation index at: https://knitkit.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# knitkit vs Module Federation 2.0: A Fair Comparison

> Compare knitkit and Module Federation 2.0 on bundler coupling, singletons, SSR, types, size, and debuggability. Pick the right tool for your use case.

Module Federation 2.0, maintained by the ByteDance Web Infra team and Zack Jackson, is the incumbent and a genuinely capable system. It ships a decoupled runtime, an `mf-manifest.json` format, first-class TypeScript type hints, a Chrome DevTools extension, runtime plugins, and Node SSR support — and it was announced in April 2024, with stable status reported by InfoQ in April 2026. If you need a batteries-included plugin with deep Webpack and Rspack integration, a large ecosystem, and automatic transitive sharing, Module Federation is a legitimate choice. knitkit makes a different bet: **radical simplicity on platform primitives**.

***

## Feature comparison

|                         | **knitkit**                                                               | **Module Federation 2.0**                                                   |
| ----------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **Substrate**           | Native import maps + ESM                                                  | Bundler runtime + share scopes                                              |
| **Bundler coupling**    | None. Runtime + manifest + a tiny CLI; externalize shared deps (one line) | Ergonomic path is `ModuleFederationPlugin`; ESM output still maturing       |
| **Shared singletons**   | One import-map entry → one instance, by construction                      | `singleton: true` + `requiredVersion` — powerful, but the canonical footgun |
| **Debuggability**       | Open DevTools → the import map shows who won and from where               | Share-scope resolution is bundler-internal                                  |
| **SSR**                 | Same manifest drives Node via `module.register`; SRI verified before exec | Supported, but labeled experimental/hard by its own creator                 |
| **Types**               | `.d.ts` published next to the manifest, synced to augment `loadRemote`    | Strong — TS hints are a praised MF feature                                  |
| **Federation overhead** | \~3.5 KB brotli (`@knitkit/runtime`)                                      | \~27 KB brotli (measured, delta method)                                     |

<Note>
  Size figures above are pinned to named versions measured with the delta method. Re-verify these numbers against the actual release versions before publishing or citing them publicly.
</Note>

***

## Where MF's worst bugs live — and why ours can't

The ecosystem's most common bug class is the dreaded *"Invalid hook call… more than one copy of React"* error. It originates from **implicit and transitive sharing**: Module Federation can silently share packages you didn't explicitly declare, and the version negotiation that determines which copy wins happens deep inside the bundler's share-scope mechanism — invisible to you unless you know exactly where to look.

knitkit's shared surface is **explicit and inspectable**. You declare every package you want shared in `knit.config.json`. The CLI emits each one as a standalone ESM asset from your installed version. The host and every remote import it through a single import-map entry — and the browser's module cache guarantees exactly one instance per URL. There is no share scope to misconfigure, no transitive sharing to accidentally trigger, and nothing is shared silently.

Open DevTools on any knitkit host and you can read the import map: one entry per package, one URL, one winner. This is *debuggability by construction* — the bug class is eliminated by the architecture, not papered over by configuration.

***

## What knitkit deliberately gives up

knitkit is not trying to be Module Federation with a different logo. These are intentional trade-offs, not gaps to fill:

* **Automatic transitive sharing.** You must declare the shared surface explicitly. This is precisely where Module Federation's silent failures originate — knitkit treats mandatory explicitness as a feature, not a regression.
* **Extracting a dep from an already-inlined bundle.** Externalization is mandatory before `knitkit build` runs. If your bundler has already inlined `react` into a chunk, you need one line of bundler config to externalize it first. This is typically a single `external` entry.
* **Cross-remote HMR.** Live module replacement across remote and host requires bundler coupling, which knitkit deliberately refuses. Each remote uses its own dev server's HMR. Use the `@knitkit/overrides` local-override widget to point any single remote at `localhost` while the rest of the system runs from deployed URLs.

***

## When to use which

**Use Module Federation 2.0** if you:

* Need deep, ergonomic Webpack or Rspack plugin integration.
* Want automatic transitive sharing and are comfortable owning the configuration required to make it reliable.
* Need a large ecosystem of community plugins and prior art.
* Require features like the Chrome DevTools extension or the MF runtime plugin API.

**Use knitkit** if you:

* Want a small, standards-native primitive you can read and fully understand in an afternoon.
* Need identical, predictable behavior across browser, Node SSR, and the edge with the same manifest.
* Value a shared surface you can see and verify — no hidden share-scope resolution.
* Care about shipping less JavaScript: \~3.5 KB brotli vs \~27 KB brotli for the federation runtime alone.