🇩🇪 Auf Deutsch lesen: Frankenstein Meeting Room: Drei Apps in einem Browser-Tab

1. Intro — Why Frankenstein?

The 2010s were the great frontend war. Many new UI frameworks emerged in this period and disappeared again. You can see this in today's enterprises' legacy applications. Many have Angular, React, Vue, or Svelte in use for various use cases. If you want to use these applications not as islands but in their entirety, the only option is usually to migrate to a common framework. A long-running and error-prone process. A better option can be to let the apps communicate with each other via a common orchestrator platform. That is the starting point for our Frankenstein Meeting Room based on Native Federation v4.

2. What the app does

The setup is meant to show how a heterogeneous web app landscape (Angular, React, Svelte) can be integrated via Native Federation. The project simulates a legacy enterprise landscape in miniature. Concretely: In an Angular 21 calendar (shell), meetings can be selected. The linked information is displayed in a Svelte 5 Mermaid diagram (Remote 1) as well as a React 18 Excalidraw whiteboard (Remote 2). When switching the meeting, the data is saved and loaded (LocalStorage).

The demo runs at lutzleonhardt.de/frankenstein-meeting-room, the code is on GitHub.

3. Starting point and workflow

In the previous article I already presented the specification of the implementation and the UI mockup (Claude Design).

The original UI mockup from Part 1, generated with Claude Design. The lab notebook look made it into the finished app.

For the implementation I used my Skill Kit for agentic workflows together with the code agents Claude Code and Codex in tandem. The agents translated the specification into individual milestone plans — in the end 18 tasks across 6 milestones. Each milestone plan was broken down into tasks. The advantage of this approach: each milestone produces a verifiable artifact that the developer can validate and review in isolation. The result then serves as the basis for the next step. For each task not only the code is produced, but also a task log: what was tried, what was discarded, which hypotheses died along the way. This negative information is almost always lost in normal commit bodies — while writing this post I had to look things up there most often.

The NF builder doesn't release the process. At your own terminal you don't notice it. You hit Ctrl-C and move on. In the agentic workflow this becomes a problem: the agent doesn't know that the work is done and keeps waiting. The workaround was a small wrapper script: delete the artifact beforehand, start ng build, poll for the artifact, then send SIGKILL to the entire process group.

4. Native Federation: Shell, Remotes, Bus

At the center of Native Federation is the shell (also called host), which loads the other web apps or exported UI components as remotes from remote endpoints. In our case the remotes are standalone web apps (Svelte, React), each of which exports a custom element for the shell.

Since no internal binding can be used for communication between the heterogeneous frameworks, an agnostic messaging pattern must be established. In the case of Frankenstein Meeting Room I decided on a simple, self-implemented pub-sub bus. The topology is star-shaped: the remotes cannot communicate with each other.

The bus implementation lies in the shared area of the monorepo, shell and remotes each import the functionality themselves. The actual bus is attached as a singleton to globalThis (window). The BusEvents were typed as DeepReadonly<T> to prevent accidental mutation across the framework boundary at compile time. A deep clone would be too costly: the entire Excalidraw data structure would have had to be cloned.

// packages/shared/src/bus.ts
type BusEvents = {
  'context:request': {};
  'event:selected': { meetingId: string; initialData: Meeting };
  'drawing:changed': { meetingId: string; excalidrawData: ExcalidrawDemoData };
  'diagram:changed': { meetingId: string; mermaidSource: string };
};
const bus = (globalThis.frankensteinBus ??= new EventTarget()) as EventTarget;
export function emit<K extends keyof BusEvents>(
  name: K, payload: DeepReadonly<BusEvents[K]>,
) {
  bus.dispatchEvent(new CustomEvent(name, { detail: payload }));
}

Star-shaped topology: all bus communication goes through the center, persistence lives with the host. Rendered live in the Svelte Mermaid editor of the demo itself.

5. M1 — Monorepo, shared package, shell skeleton

In the first milestone I set up the pnpm monorepo and implemented the types as well as the bus in the shared package. Via a Native Federation schematic the Angular project is then converted into a Native Federation shell. At the core, the project gets an adapted build, a slightly modified bootstrap process, and a federation configuration. The bootstrap runs in two stages: the shell first loads the federation manifest, injects the import map, and only then starts the actual Angular app. The configuration defines which dependencies are shared between shell and remotes.

That's another advantage of Native Federation: depending on the configuration, libraries are loaded only once, even if multiple remotes and the shell use them.

6. M2 — Host complete: calendar, meeting service, panels

In milestone 2 I completed the shell by adding the calendar (Schedule-X). There is also a meeting service that manages the current meetings based on signals, receives messages via the event bus, and sends data, for example to initialize the remotes with the active meeting. Initially the meetings are populated by a seed. On changes they are saved in LocalStorage and loaded from there again on start. In the shell there are two more Angular components: the detail view for the active meeting as well as an overview of the bus messages. The layout is three-column: calendar on the left, remotes in the middle, detail view and bus log on the right.

A small detail in the meeting service: the remotes debounce their updates (500 ms), and without a guard a meeting switch in the middle of the debounce would lead to the old draft overwriting the new meeting. The fix: every applyDrawingChange/applyDiagramChange in the service checks the meetingId against currentMeeting and drops stale updates. One line of code, without which the bus would have had subtle data corruption.

private applyDrawingChange(p: DrawingChangedPayload): void {
  if (p.meetingId !== this.currentMeeting()?.id) return; // stale-update guard
  // ... persist
}

In the middle area of the shell the React and Svelte applications now still need to be integrated.

7. M3 & M4 — Whiteboard and Mermaid as remotes

In milestones 3 and 4 I implemented the React whiteboard (Excalidraw) and the Svelte Mermaid diagram each as a remote. For both I proceeded the same way: first the standalone app, then placed the federation configuration on top. That way I could develop and test Excalidraw or the Mermaid diagram in isolation before the remote was integrated into the shell. The same UI project (react, svelte) continues to run under its own port as a standalone app and can at the same time be loaded by the host as a remote — for the federation loading, however, the built JavaScript chunks plus remoteEntry.json as static assets are sufficient, a running dev server is not necessary (only for the standalone test).

@frankenstein/shared as devDependency, not as dependency. That way shareAll skips the package, and the globalThis singleton from Section 4 stays intact — the conceptually most important build-mode decision of the project.

Excalidraw spam without real changes. Excalidraw's onChange fires even without real changes. When resizing the window I got ~8 drawing:changed events in 11 seconds without anyone having drawn anything. I had already built in the 500 ms debounce at the sender — but it only groups the events together, it doesn't recognize whether anything has actually changed. The real fix was a fingerprint over ${element.id}:${element.version}: Excalidraw only bumps version on real changes, not on cosmetic reflows. With that the empty events fall out before the debounce, and afterwards it only takes care of the frequency of real edits.

const fp = elements.map(e => `${e.id}:${e.version ?? 0}`).join('|');
if (fp === prevFingerprintRef.current) return; // skip cosmetic re-renders
prevFingerprintRef.current = fp;
// → 500ms debounce → emit('drawing:changed', …)

Firefox canvas limit. Firefox caps <canvas> at ~11180 px edge length. Since Excalidraw's stylesheet was only loaded after the React mount, the container was briefly large; Excalidraw computed a canvas size beyond the limit, and the first setTransform call threw an exception with a stack trace in the console — Excalidraw didn't even boot. Chromium doesn't have the limit: classic "works on my machine" bug. Solved by injecting the stylesheet into the head already at module init and having the first render wait for its load event.

The federation configuration is set up the same way for both remotes: a federation.config.mjs in which it is specified what the remote exports and which libraries are shared. Shared libraries are usually loaded as singletons — exactly one instance for shell and all remotes, even though each project brings them in as a dependency itself. Version conflicts are resolved at build time, transitive sub-dependencies are explicitly shared or excluded. With that the federation configuration ultimately also determines how many JavaScript chunks are produced per application.

React jsx-runtime as CJS. React still ships some modules as CommonJS, which Native Federation converts to ESM during the build. With one specific pattern — react/jsx-runtime — this translation doesn't work cleanly: the jsx function was undefined at runtime and Excalidraw blew up on the first render. Fixable via path mapping in the federation configuration, which skips the problematic intermediate step and points directly to React's pre-compiled CJS file.

Svelte twice in the tab. In the Mermaid remote it was the other way around: Svelte couldn't be shared cleanly at all. Its internal code references itself via relative paths that the federation mechanism can't reach — in the end two Svelte runtimes ended up in the tab in parallel, and Mermaid threw effect_orphan at runtime. Pragmatically solved: Svelte out of the share map and bundled directly into the Mermaid bundle. With only one Svelte app the size doesn't matter — the ~160 kB ends up on the client either way, whether as a shared chunk next to the bundle or as part of it. Only from two Svelte remotes onwards would the duplication start to bite.

8. Islands instead of components

In a homogeneous landscape — that is, when all apps use the same UI framework — you would export components directly and use them in the shell. In a heterogeneous landscape this doesn't work: if I only exported the React component from the React project, the Angular shell could not load it because the React runtime is simply missing in the tab. A pure component has no platform underneath it.

The solution is islands: each remote exports not just the component, but the complete app including its framework. In the tab one UI framework then runs per island, fully encapsulated. Technically this happens via native custom elements: the remote defines a <whiteboard-remote> (or <mermaid-remote>), the shell renders the tag like any other DOM element, and in the connectedCallback the embedded framework boots. That's exactly how whiteboard and Mermaid are implemented in milestones 3 and 4.

class WhiteboardRemote extends HTMLElement {
  connectedCallback() {
    this.root = createRoot(this);
    this.unsubs.push(on('event:selected', ({ initialData }) => {
      this.render(initialData);
    }));
    emit('context:request', {});
  }
  disconnectedCallback() {
    this.unsubs.forEach(u => u());
    this.root?.unmount();
  }
}
customElements.define('whiteboard-remote', WhiteboardRemote);

React DevTools see the full component tree (left). Wappalyzer finds no React (right). The island works.

9. Bus access and events

Shell and remotes each import the bus directly from the shared package (see Section 4). The central, non-trivial part is the init handshake between remote and host: On mount a remote doesn't yet know which meeting is currently active — the host holds the state. So after its initialization the remote sends a context:request over the bus and gets back from the host an event:selected with the current meeting. Only with that does it know which whiteboard or Mermaid data it should load. The two remaining events (drawing:changed, diagram:changed) are pure change notifications from the remotes towards the host.

The event bus log live: context:request on mount of a remote, event:selected as host response, then drawing:changed for an actual whiteboard change.

Deliberately not in the setup: creating or editing meetings via the bus. That would have pulled CRUD wiring through all three frameworks without adding anything to the integration pattern itself. What is possible with Native Federation can be shown clearly with this minimal event set as well.

10. M5 & M6 — Polish and deployment

The last two milestones were about polish and deployment. M5 was fine-tuning: improved the CSS, did cleanups, created a representative seed. The seed has a small punchline: instead of lorem ipsum meetings, the demo meeting is an "Architecture Review" of the demo itself. The whiteboard draws three boxes plus bus, Mermaid shows the sequence diagram of the bus flow. The hero image of the post follows from that on its own.

M6 was the deployment to https://lutzleonhardt.de/frankenstein-meeting-room/ — all static under a subpath, no backend, plus the two remotes separately under /whiteboard/ and /mermaid/ as standalone apps. During development each remote ran via its own standalone dev server, the federation manifest pointed to localhost URLs accordingly. After the build the remotes migrate as static assets into the subpaths of the host, and the manifest is adjusted to match.

11. Take-away

The whole setup stood in 10 to 12 hours of net effort, with the help of the agentic process and consistent curation. Extending it is easy: further React applications can be plugged in just like an additional framework, for example Vue. That makes Native Federation a good fit for bringing a grown heterogeneous legacy landscape together onto one platform without having to pull off a big migration.

What the setup deliberately does not cover: authentication and authorization, cross-origin hardening, multi-user collaboration, contract versioning between host and remotes, e2e tests across island boundaries, mobile layouts. These are not the hard NF topics — but the topics that come in addition to NF in a real enterprise migration. The full delimitation is in the README.

Particular pitfalls exist mainly when multiple versions of the same framework run in parallel — for example Angular 15 and Angular 17 in the same platform. Then you have to pay close attention to shared dependencies, sub-dependencies, and transitive dependencies. The loading of dependencies runs centrally via the native import map, though, which keeps it manageable. In contrast to Webpack Module Federation, where the remote map was buried deep in the code.

Conclusion: the friction between three frameworks in one tab is not where you would expect it. Bus and loading ran without problems. Complications arose with the Firefox CSS, the React CJS wrapper, and a Svelte compiler that ran twice in the same page. The code is at github.com/lutzleonhardt/FrankensteinMeetingRoom.

If you have such a landscape in front of you yourself and don't know whether to migrate or federate — write to me on LinkedIn. The problem points that don't come up in standard talks interest me the most.

Lutz Leonhardt is a member of the Native Federation Advisory Board. More at lutzleonhardt.de.