Introduction

Mountly puts a React, Vue, or Svelte component on a page that does not use that framework. Two ways:

Embeds: publish the component as a custom element behind one script tag. The consuming page installs nothing. Start at Script-tag embeds.
Runtime: a page you own runs Mountly and loads widgets on user intent, sharing one framework instance. Start at the Quick start.

Embeds or runtime? is the short table. Positioning states the job and the limits.

If you want embeds, stop here and open Script-tag embeds. The rest of this page is the runtime vocabulary.

Runtime shape

You write ordinary components. An adapter wraps each as a widget (mount / unmount). createOnDemandFeature or defineMountlyFeature adds the lifecycle: trigger, loader, optional data fetch, cache, state machine.

Component: your React / Vue / Svelte UI.
Widget: component plus adapter. Knows nothing about when.
Feature: widget plus on-demand lifecycle. Code API or <mountly-feature>.

Where the runtime fits

Marketing and CMS pages that drop HTML tags
Legacy shells you modernize one region at a time
Intent loading (idle, viewport, click, hover, media, URL)
Several frameworks on one page during a migration
Many widgets on a page you run, sharing one framework copy

Partner and CMS drops that should install nothing are usually embeds, not this track.

Who it is for

Framework components on pages you do not fully own
HTML-addressable tags with little host wiring
Intent-based activation and a shared module / data cache
Optional shadow: true when host CSS would fight the widget
Multiple widgets on one page, including mixed frameworks

If one framework owns every surface, use its lazy routes. If you need SSR hydration, use that framework’s islands. If you need staged rollouts inside the composition layer, use a platform built for that. See When not to use mountly. For release boundaries, see Choosing an architecture.

Where to next

For the runtime: