> ## 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 Native Federation: Key Differences

> How knitkit differs from Angular Native Federation: zero Angular dependency, universal runtime, manifest-driven negotiation, and edge support.

[Native Federation](https://github.com/angular-architects/native-federation), created by Manfred Steyer at Angular Architects, is knitkit's closest philosophical sibling — and it deserves credit for proving that import-map-based federation is viable in production. Like knitkit, it builds on **native import maps + native ESM** rather than a bundler runtime, rejecting the share-scope machinery that gives Module Federation its footguns. If you are evaluating knitkit and have not already looked at Native Federation, read their project first; the approach is sound and the Angular tooling is mature.

The difference between the two projects is positioning and scope.

***

## Feature comparison

|                             | **knitkit**                                                                                                                         | **Native Federation**                                                                                   |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Primary audience**        | Framework-agnostic (React, Vue, Svelte, vanilla JS)                                                                                 | Angular-first in practice                                                                               |
| **Framework-agnostic core** | The whole project is the framework-neutral core                                                                                     | `@softarc/native-federation` exists but has limited independent mindshare outside the Angular ecosystem |
| **SSR**                     | First-class `@knitkit/node`: loader hooks, SRI verification, module cache, hydration-parity import-map serialization                | Not the focus                                                                                           |
| **Edge**                    | `@knitkit/edge`: ESI-style fragment stitching for Cloudflare Workers, Deno Deploy, Vercel Edge (Web-standard `fetch` + Web Streams) | Not the focus                                                                                           |
| **Types**                   | `knitkit types generate` + `knitkit types sync` augment `loadRemote` with per-remote TypeScript types                               | —                                                                                                       |
| **DX**                      | `<RemoteComponent>`, local-override widget, coded `FedkitError` instances                                                           | Angular CLI / Angular Architects tooling                                                                |
| **Singleton enforcement**   | Manifest-driven version negotiation; SRI on all shared assets                                                                       | Import-map-based, similar approach                                                                      |
| **Bundler requirement**     | None at runtime; optional CLI for building shared assets                                                                            | Angular CLI / custom builders expected                                                                  |

***

## The gap knitkit aims at

Native Federation showed that the import-map federation approach works. What nobody yet owns is *"framework-agnostic, runtime-first, SSR + edge, great DX"* on import maps.

knitkit's goal is to be the **framework-neutral, SSR-and-edge-capable** take on the same substrate — with a versioned manifest spec as a shared foundation the ecosystem can build on, and without any Angular-shaped assumptions baked into the runtime. The `@knitkit/runtime` package is under 5 KB, has zero dependencies, and works identically in the browser, in Node via `module.register` loader hooks, and at the edge via the Web Streams API.

***

## When to prefer Native Federation

* You are running an **Angular** application and already use the Angular CLI and Angular Architects tooling. Native Federation integrates deeply with that ecosystem and you will get better out-of-the-box support.
* Your team's expertise is in the Angular toolchain and you do not need SSR or edge composition outside of Angular Universal.
* You want a solution with an established community of Angular developers who have already debugged the edge cases in your stack.

## When to prefer knitkit

* Your host or remotes are built with **React, Vue, Svelte, or vanilla JavaScript** — or you need to federate across multiple frameworks.
* You need **Node SSR** with SRI enforcement, or **edge composition** (Cloudflare Workers, Deno Deploy, Vercel Edge) using the same manifest as your browser build.
* You want `loadRemote` to be **fully typed** via a CLI-driven type-sync workflow without Angular tooling.
* You want a runtime you can read in full in one sitting and a manifest spec you can implement yourself.

<Note>
  The descriptions of Native Federation's roadmap and ecosystem above reflect public information at the time of writing. Re-verify the project's current SSR and edge support before making a tooling decision based on this comparison.
</Note>