When microfrontends are composed on the client using native Web Components (custom elements with Shadow DOM) as the integration contract, what isolation does Shadow DOM actually provide, and what does it NOT protect against compared to a full cross-origin iframe boundary?

## The integration contract Web Components give microfrontend composition a **browser-native integration contract**: each microfrontend registers a custom element via the Custom Elements API, and the host page simply drops that tag into its markup wherever the microfrontend should render — no bespoke mounting API, no framework-specific adapter, just an HTML tag any framework (or no framework) can consume. Inside that custom element, the microfrontend typically attaches a Shadow DOM, which creates a separate, encapsulated DOM subtree hung off the custom element. ## What Shadow DOM actually isolates Shadow DOM's isolation is **real and specific**: - **CSS selectors written inside the shadow tree** cannot select elements outside it, and — critically for microfrontends, where five teams' CSS living on one page is normally a recipe for cascading collisions — CSS rules defined at the document level do not apply inside the shadow tree either, aside from a deliberately designed set of exceptions. - **Inherited CSS properties** (like `font-family` or `color`) still cascade in through the boundary, and **CSS custom properties** are explicitly designed to pierce the shadow boundary so a host page can pass design tokens down to a microfrontend without breaking encapsulation. - **Querying the document** for elements does not reach into a shadow tree by default in open mode without explicitly walking into the element's shadow root, and closed mode additionally hides that shadow root property, blocking even that explicit walk. - **DOM events** that originate inside the shadow tree are retargeted as they cross the boundary, so listeners on the host page see the event as coming from the custom element itself, not from whatever internal element actually fired it — this preserves encapsulation of internal structure while still letting the host react to, say, a click. | Mode | Reaching the shadow root from a document query | |---|---| | open | the shadow root, by explicitly walking into the element and querying from there | | closed | the shadow root property itself is hidden, blocking even that explicit walk | ## Where the isolation stops This gives teams most of the visual and structural benefits people reach for iframes for — no CSS bleed in either direction, internal markup structure hidden from the host's DOM queries and devtools inspection by default — while staying in the same document, same DOM tree, same JS realm as the rest of the page. That last point is exactly where the isolation stops. Every custom element on the page, regardless of which team wrote it, executes as regular JavaScript in **one shared global scope**: they all see - the same `window`, - the same built-in prototypes, - the same document-level event loop. A microfrontend with a runaway timer, a memory leak, or a script that overwrites a shared built-in prototype method for convenience affects every other microfrontend on the page exactly as it would with plain JS-bundle mounting — Shadow DOM does nothing to stop it, because Shadow DOM is a DOM/CSS isolation primitive, not a JavaScript execution sandbox. A cross-origin iframe, by contrast, gets a genuinely separate JS realm enforced by the browser's process/origin model, so this class of failure literally cannot cross that boundary uninvited. ## The Custom Elements registry collision A second, easy-to-miss failure mode is specific to the Custom Elements registry: registering a custom element is a **single, page-global, append-only operation** — a given tag name can only be defined once per document, and calling define twice with the same name throws. In a microfrontend world where two independently-deployed teams might both want to register the same tag name (or, worse, two different versions of the same team's component get loaded together during a rolling deploy), this becomes a real coordination problem: teams must adopt naming conventions such as prefixing tags with a team or product namespace, or a second microfrontend's registration attempt throws at runtime and its widget silently fails to render — a bug that, like the shared-global collision above, only shows up when two specific microfrontends happen to be composed on the same page together, making it hard to catch in isolated per-team testing. ## The middle position on the spectrum The practical upshot is that Web Components sit in a genuine **middle position on the isolation spectrum**: stronger than a bare JS-bundle mount for CSS and DOM structure, but no stronger than that same bare mount for JavaScript execution and global-scope safety. Teams choosing this approach are usually optimizing for a specific pain point: - CSS collisions across independently-styled teams, - or framework-agnostic composition so a React-based host can embed a Vue-authored widget without a framework adapter, while accepting that isolation for buggy or malicious code still needs other tools: - strict lint rules against modifying globals or built-in prototypes, - careful namespacing of the Custom Elements registry, - and treating a genuinely untrusted third party as an iframe case regardless of how appealing the web-components developer experience is. This is why organizations that adopt web-components-based microfrontends (a pattern popularized alongside compiler tooling like Stencil that outputs standards-based custom elements) usually pair it with strong internal governance over global mutations and naming, rather than treating it as a substitute for iframe-grade security isolation.