This strategy grew out of my attempt to design an architecture around value streams: independent teams needed to own, develop, test, deploy their own code. Once changes were ready for release, they just need to promote their work. At which point the runtime dynamically loads their latest changes into the product. But independence alone wasn’t enough. If achieving it required every team to understand a complex composition framework or maintain layers of specialized configuration, the architecture would simply exchange delivery friction for cognitive load. I wanted a strategy built around a small, shared convention—one that preserved team autonomy while keeping the overall system understandable. That search eventually led me to browser-native primitives, particularly ES modules and import maps, as the foundation for Runtime Module Composition.
If you've worked on a large web product, you've probably lived through this: five teams, one page, and a build pipeline that's grown a webpack config nobody fully understands anymore, with small changes triggering an entire suite of tests. Splitting a page into independently built, independently deployed pieces are supposed to solve the "five teams, one page" problem. In practice, most micro-frontend tooling solves it by adding another layer of build-time complexity on top.
There's a simpler answer sitting in every modern browser already: import maps. They let a page say "when someone imports react, actually fetch it from this URL", no bundler required, no custom module loader, no iframes. walks through wiring up a small React (or Vue) host and one slice end to end, running locally in under a dozen steps.
Learn more
— the pattern itself, independent of this specific toolkit
— every exported method, with usage examples
SOCIAL SHARE CARD GENERATOR