Introduction
mountly is an on-demand component runtime:
Framework components. Any page. On demand.
It turns React, Vue, Svelte, and TSRX components into lazy, HTML-addressable features (light DOM by default; shadow: true for isolation). The host can be a CMS page, marketing site, legacy app, static file, partner embed, or another framework app.
The performance problem still matters: modern web apps ship too much JavaScript upfront. But mountly’s deeper job is component delivery. It lets a page load a real component only when the user or route actually needs it, without forcing the host into a new app framework.
The shape of it
Section titled “The shape of it”You write components the way you already do — React, Vue, Svelte, or TSRX. The framework adapter wraps each component as a widget: a self-contained, mountable, framework-agnostic unit. createOnDemandFeature or defineMountlyFeature then adds a lifecycle around the widget — a trigger (hover, click, focus, viewport, idle, media, url-change), a module loader, optional data fetching, dual caching, and a standardised state machine.
The vocabulary is enforced in the docs because it pays off:
- Component — your normal React/Vue/Svelte component. Nothing new to learn.
- Widget — a component wrapped by an adapter. Has
mountandunmount. Knows nothing about when. - Feature — a widget plus the on-demand lifecycle. Built with
createOnDemandFeatureor declared with<mountly-feature>.
You write components, the adapter wraps them as widgets, and you ship them as features.
Where it fits
Section titled “Where it fits”- Marketing surfaces — reuse real product components on fast campaign pages.
- Legacy modernization — replace old UI one feature at a time without rewriting the host.
- Runtime islands — get island-style activation in HTML hosts without adopting a site framework.
- Partner and CMS embeds — expose stable custom tags that non-app teams can place safely.
- Performance-sensitive pages — pay for heavy UI on idle, viewport, click, hover, media, or URL change.
- Framework transitions — run React, Vue, Svelte, and TSRX widgets side by side while migrating.
Who it’s for
Section titled “Who it’s for”mountly is appropriate when:
- You need to ship framework components into pages you do not fully own.
- You want HTML-addressable components like
<signup-card>with minimal host wiring. - You need intent-based activation with a shared module and data cache story.
- You want style isolation when needed (
shadow: true) so the host page and component do not break each other in unknown hosts. - You need multiple widgets on one page, potentially from different frameworks.
It’s the wrong tool when you have a single SPA where the bundler owns every surface, when you need SSR + hydration of server-rendered HTML, or when you actually want a microfrontend control plane. See When not to use mountly for the longer answer.
How it compares
Section titled “How it compares”| Approach | Best at | Tradeoff | Complexity |
|---|---|---|---|
| Traditional SPA | One app owns every surface | Poor fit for CMS, legacy, or partner-hosted UI | Low |
| Framework code-splitting | Routes inside one framework app | Does not standardize HTML drops or host-agnostic lifecycle | Medium |
| Microfrontend orchestrators | Independent apps with team ownership | Operationally heavy for component-sized features | High |
| mountly | Component features in any HTML page | Not a router, SSR framework, or microfrontend control plane | Low |
Where to next
Section titled “Where to next”- Quick start — scaffold and ship your first widget in 60 seconds.
- How it works — read the architecture before you commit.
- Vocabulary — the three terms you’ll see everywhere.