# Pure Native Micro-Frontends For decades, we were told we needed heavy third-party framework compilation layers just to slice code layout efficiently — we were told wrong. This article introduces the **Remote Module Definition (RMD)** pattern, which removes this bottleneck natively inside the browser’s raw engine. By returning to first principles, the RMD pattern has turned the web into an open plugin architecture and set the baseline for entirely new web architectures and new web markets. ## A Brief History of Native Includes The challenge of native component inclusion is not new; the web development community has been trying to solve this bottleneck for over thirty years. This persistent dilemma dates back to early server-side architectures and client-side hacks of the 1990s and 2000s, including Apache Server Side Includes (SSI), the highly controversial frameset era, and primitive patterns involving hidden iframes. By the early 2010s, the conversation shifted to community Q&A forums, where developers frequently sought clean patterns for template injection. A notable milestone occurred around 2013 when the W3C introduced the HTML Imports specification — arguably the industry's most coordinated attempt at a native solution. Despite initial enthusiasm and widespread documentation across community hubs, the specification failed to gain universal browser consensus and was officially deprecated in 2023. The RMD pattern is something you can apply today that scales for tomorrow as it cleanly solves this problem for us. ## The RMD Predecessor: A Custom Element The RMD pattern itself went through several important iterations — the latest being this custom element. ### Custom Element Definition ```javascript const TAGNAME = 'nwf-partial'; const defined = !!customElements.get(TAGNAME); if (!defined) customElements.define(TAGNAME, class NativeWebFederationIncludeElement extends HTMLIFrameElement { #handleLoad = (e) => { const { contentDocument } = this; const content = contentDocument.querySelector('.partial.content'); // expects there to be an element such as *[class="partial content"] this.outerHTML = content.outerHTML; // effectively replaces this node with the content of the .partial.content element }; connectedCallback() { this.addEventListener('load', this.#handleLoad, true); } disconnectedCallback() { this.removeEventListener('load', this.#handleLoad, true); } }, { extends: 'iframe' }); ``` ### Importing The Partial ```html
``` > *After the Custom Element is pulled in and defined, we can extend an iframe and point it to any partial we want to include.* ### The Partial ```html

Custom Element Partial

``` > *Defines* `./partial.rmd.html` *using a conventional* `[class="partial content"]` *element, as required by the custom element.* ### Output ```html

Custom Element Partial

``` --- ## Deconstructing The Custom Element Solution ### The Breakdown The `NativeWebFederationIncludeElement` simply extends the `HTMLIFrameElement` class so that every instance (`iframe[is="nwf-partial"]`) handles its own scope, as opposed to tracking & mapping everything in a top-down system fashion. When the child frame loads, the Custom Element simply queries its own document for the conventional `.content.partial` target before replacing itself with the content, similar to using `this.replaceWith(content)`. ### Limitations This approach arguably packages the old, top-down 'hidden iframes' approach into a single, small system so that there is no complicated mapping & handling between the content source and outlet, largely reducing the chance for errors. But this approach has some issues; while it is no longer a top-down system, it is still a stepwise system in the RMD's outer scope, so the Custom Element must make all kinds of assumptions about the target RMD's inner structure and intentions – essentially, *Content/Pathological Coupling*. In addition to that, the small amount of boilerplate overhead — alongside the aforementioned assumptions — makes this implementation less portable across different codebases without additional tooling (*compounding those assumptions*). What if we used a bottom-up system instead? --- ## The RMD Pattern Essentially, we leverage a type of IoC (Inversion of Control) on the Custom Element solution by converting the Custom Element into a simplified pattern that flips the system on its head and delegates all assumptions to the partial, itself. Better yet, as you'll see below, we naturally get a fully native *Single File Component (SFC)* syntax, as seen in frameworks like Svelte and Vue. This natural syntax, however, can be jailbroken if the developer decides to separate code into their own files and import them in the RMD using `script[src]` and `link[href][rel="stylesheet"]` instead. In fact, the RMD pattern even allows you to import `