Delivery modes

Six ways to get a surface into a host that did not ask for it, scored on the six axes you do not get to choose. Open this page when a new host arrives, and work the axes in the order the delivery-constraints lesson sets out — eliminate on their response headers and their build first, then score what survives.

Nothing here scores well on everything, and a mode that scores Weak on an axis you do not care about in this host is not disqualified. The scores are a prompt for the question “does this host care about this axis,” not a ranking to sum.

The multiplier comes first

Write down how many hosts this has to work in before you read a single row. At one host, the native rewrite wins on almost every axis and you should take it. At ninety, it is the only option on the table that does not amortise, and the mechanism that is second-best everywhere beats the mechanism that is best once.

Custom element / Web Component

An autonomous custom element, usually with a shadow root, shipped as one script the host loads.

Style isolationStrong: Selector-based styles do not cross in either direction. Inherited properties and every custom property still do, because inheritance is computed over the flattened tree.
Auth inheritanceStrong: Same document, same origin, same cookies. Whatever session the host has, you have.
CSP survivabilityMixed: Needs your origin in script-src, and your API origin in connect-src. A nonce or strict-dynamic policy means the host must render your script tag rather than you loading yourself.
Accessibility across the boundaryWeak: ID references do not cross tree boundaries, so a host label cannot point at a control inside your shadow root. Element reflection helps only outward. No fix ships in all engines today.
Bundle costMixed: No framework needed for the element itself; the cost is whatever you put inside it, and duplicating a framework the host already ships is the failure mode.
Host-team burdenStrong: One script tag and one mount element. No build change, no framework version negotiation. This is the axis it wins on and the reason it is usually the answer.

Pick it when: The default at high host counts. Pick it unless a specific host fact rules it out.

Module Federation

Runtime remote module loading with a shared dependency graph, configured in both builds.

Style isolationWeak: None by default. You are shipping modules into their document with their cascade; isolation has to be added separately, usually by putting a custom element inside anyway.
Auth inheritanceStrong: Same document and origin. Session is inherited for free.
CSP survivabilityMixed: Remote entry must be allowed by script-src. Runtime loading from a second origin is exactly what strict-dynamic and allowlists are designed to constrain.
Accessibility across the boundaryStrong: No boundary is introduced, so nothing about ARIA changes. Accessibility is as good or bad as the code you wrote.
Bundle costStrong: The best on this axis when it works: shared singletons mean the framework is loaded once for host and remote together.
Host-team burdenWeak: Requires the host to change its build config and adopt a compatible bundler and version. That is a platform-team conversation before a line of your code runs.

Pick it when: The host already runs it. Adopting it for your sake alone is rarely proportionate.

single-spa

An orchestration layer: a root config registers applications and mounts or unmounts them as routes activate.

Style isolationWeak: Nothing inherent. It solves when an application runs, not what its styles touch.
Auth inheritanceStrong: Same document and origin.
CSP survivabilityMixed: Same shape as any runtime-loaded remote: your origin must be allowed to serve script.
Accessibility across the boundaryMixed: No boundary introduced, but the mount/unmount lifecycle is where focus and live-region state get lost between applications.
Bundle costMixed: Shared dependencies are possible but are not the framework’s job — that is usually Module Federation’s, and the two are commonly combined.
Host-team burdenWeak: The host must restructure its bootstrap around a root config. Larger than a build change: an architectural adoption.

Pick it when: The host already runs it, or the real problem is routing between several applications rather than embedding one surface.

iframe + postMessage

A separate document embedded in theirs, with every interaction serialised across an origin-checked message channel.

Style isolationStrong: The only true isolation on this table. Nothing crosses, including inherited properties — which also means no brand inheritance for free.
Auth inheritanceWeak: A third-party context. Cookies need SameSite=None; Secure at minimum, and cross-context storage access is its own negotiation. The hardest axis on this row.
CSP survivabilityWeak: Both directions must permit it: the host must be allowed to embed you by your frame-ancestors, and their frame-src must allow your origin. Either one alone kills it.
Accessibility across the boundaryWeak: A document boundary is stronger than a shadow boundary — no ARIA relationship crosses it at all, and focus order between host and frame is a known rough edge.
Bundle costMixed: Fully independent, so nothing is shared with the host — the same property that makes it safe makes it duplicative.
Host-team burdenStrong: One tag, no build change, and the smallest blast radius on the table: your code cannot break their page.

Pick it when: Hostile or unknowable hosts, hard security boundaries, or anywhere you must guarantee you cannot break their application.

Plain script tag into a div

A script that finds a mount element and renders into the light DOM, with no shadow root.

Style isolationWeak: None. You are in their cascade with nothing between you, and you are relying entirely on naming discipline in both directions.
Auth inheritanceStrong: Same document and origin.
CSP survivabilityMixed: Same as any third-party script: script-src for you, connect-src for your API.
Accessibility across the boundaryStrong: No boundary at all, so every ARIA pattern works normally and host labels can reference your controls.
Bundle costMixed: Whatever you ship, plus a real risk of duplicating a framework the host already has.
Host-team burdenStrong: The lowest-friction install that exists, which is why it is still the most widely deployed widget mechanism on the web.

Pick it when: Simple surfaces in hosts with a clean, low-specificity stylesheet — or where accessibility across a boundary is the binding constraint and isolation is not.

Native rewrite in the host’s framework

Build the surface again, in their stack, with their components and their tests.

Style isolationStrong: Not applicable in the best way: there is no foreign object, so there is nothing to isolate.
Auth inheritanceStrong: It is their application.
CSP survivabilityStrong: Nothing to allow. No policy conversation at all.
Accessibility across the boundaryStrong: No boundary, their patterns, their audit. The best available answer on this axis.
Bundle costStrong: No duplication of anything, and tree-shaken into their existing build.
Host-team burdenWeak: Enormous, but deferred: cheap to install and expensive forever, because they now own and maintain a second implementation of your surface.

Pick it when: One host, or a strategically important host where nothing else clears review. Never as a portfolio-wide strategy — it is the one option that does not amortise.

What the scores are grounded in

Every score above rests on a documented behaviour rather than an impression. The load-bearing ones, with the date each was checked:

Shadow DOM isolates selectors, not inheritance. MDN states page CSS does not affect shadow nodes and vice versa, while CSS Scoping Level 1 establishes that inheritance is computed over the flattened tree, which is why inherited properties and custom properties still cross.
ARIA ID references do not cross a shadow boundary, and the fix is not shipping. MDN: ID references are “only in-scope for target elements declared in the same DOM or shadow DOM,” and reflected element properties reach a parent DOM but never into a child shadow DOM. The proposed Reference Target is a WICG proposal without a formal specification, and is behind flags in Firefox and Safari as of 2026-09-03.
frame-ancestors is the iframe gate, and header-only. MDN distinguishes it from frame-src — who may embed you, versus what you may embed — and notes it is not supported in a <meta> element.
A nonce silently disables ‘unsafe-inline’. MDN: “If a directive contains nonce or hash expressions, then the unsafe-inline keyword is ignored by browsers.” A policy containing both is not permissive.
Module Federation’s shared-singleton behaviour. Per its own documentation — a project documenting its own product — without singleton, “if the shared dependencies between the producer and the consumer have different versions, each side will load its own dependencies.” That duplication is what breaks React hooks in a federated graft.
Iframes do not size to their content, deliberately. MDN gives defaults of 300×150 CSS pixels, and the frame-sizing page explains why: “For security and privacy reasons, <iframe> elements do not by default expose any information to the parent document about the size of the content in the document they are embedding.” That standards-track fix had limited availability as of 2026-09-03, so a postMessage height shim is still required in production.
postMessage needs an origin check you write yourself. MDN: “Always provide a specific targetOrigin, not *,” and on receipt “always verify the sender’s identity using the origin and possibly source properties.”
Sandboxing an iframe with both allow-scripts and allow-same-origin is self-defeating for a same-origin frame. MDN warns the combination “lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.”

One thing this table does not claim

Whether constructed stylesheets (adoptedStyleSheets and CSSStyleSheet.replaceSync()) are subject to a host’s style-src directive is not documented in any primary source found for this course. MDN covers insertRule() and cssText, and notes that no browser currently blocks them, but says nothing about constructed stylesheets either way. What is documented is that a runtime <style> injection is blocked without 'unsafe-inline' or a nonce — which is why CSS-in-JS needs nonce plumbing in a strict host. Test the constructed path against the specific host rather than assuming either answer.

Browser behaviour on these pages is dated on purpose — support for shadow-DOM, form-association and ARIA-reflection features has moved repeatedly, and a claim without a date is a claim that will quietly rot. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.