Positioning

Mountly helps you put a React, Vue, or Svelte component on a page that does not use that framework.

Most teams start by publishing the component as a custom element. You point a Vite build at the files and choose a tag prefix. The other team adds one script tag and writes the element. Attributes and events come from the component’s props type. Their page does not install Mountly.

export default defineElementsConfig({ prefix: "acme", elements: "src/elements/*.tsx" });

<script type="module" src="https://ui.acme.com/payments/1.2.0/embed.js"></script>
<acme-payments-summary balance="1250" currency="GBP"></acme-payments-summary>

If you run the page yourself and want many widgets to share one framework copy, use the runtime instead. Mountly loads each widget when a trigger fires (click, viewport, idle, and so on). That path asks more of the host: an import map or a bundler, and a shared React (or Vue, or Svelte) version.

Pick which half you need in Embeds or runtime?. A third host is an MCP client (Claude, ChatGPT); that path lives under MCP Apps.

Who this is for

Product teams that own a slice of the product and need that UI on a page someone else runs: a CMS template, a marketing site, a partner shell, a legacy app, or another team’s platform. You keep the component, the deploy URL, and the contract. They keep the page.

It also fits a page you do run, when you want HTML tags and intent-based loading without pulling every widget into the first paint.

What you get

• A build that turns ordinary components into tags, with types and a custom elements manifest for editors.
• Lazy load by default: embed.js registers tags; component code and CSS arrive when an element connects.
• Light DOM so the host’s design tokens can reach in; shadow: true when you need style isolation. Neither is a security boundary. Untrusted hosts need an iframe. See When to frame.
• On the runtime track: triggers, a shared module cache, and <mountly-feature> or data-mountly for hosts that already run Mountly.

The trade on embeds is one framework copy per distribution. That is fine for one team’s components on a foreign page. For eight widgets on a page you control, use the runtime.

What Mountly leaves alone

• Your app framework still owns the shell, routes, and SSR when you have one.
• Your CDN and release process still own versions, rollouts, and traffic.
• Components stay React, Vue, or Svelte. You write them the same way you do today.

When not to use mountly covers the cases where the framework’s own lazy loading or hydration is enough. For release boundaries and multi-team shells, see Choosing an architecture.