Skip to content
mountly

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 main job is component delivery. A page loads a real component only when the user or route 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, in 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.

These docs use three terms consistently:

  • Component: your normal React/Vue/Svelte component. Nothing new to learn.
  • Widget: a component wrapped by an adapter. Has mount and unmount. Knows nothing about when.
  • Feature: a widget plus the on-demand lifecycle. Built with createOnDemandFeature or 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 plus hydration of server-rendered HTML, or when you want a microfrontend control plane. See When not to use mountly and Choosing an architecture for the longer answer.

How it compares

Section titled “How it compares”

Not sure where mountly fits? Start with Choosing an architecture — most teams should try a monorepo or widget drop-in before adopting micro-frontend orchestration.

Approach When Pain you accept Complexity
Monorepo npm lib Same org, shared CI OK Merge coordination Low
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
mountly widget drop-in Foreign host, 1–5 interactive regions Import map / version pinning Low
mountly manifest verticals 2–5 teams, independent CDN widget deploys Shared React version agreement Low
Module Federation Deep horizontal integration, shared build graph shared blocks, tooling complexity High
Single-SPA / vendor MFE Full app shells per route, many teams Orchestration, routing ownership High
Microfrontend orchestrators (generic) Independent apps with org-level ownership Operationally heavy for component-sized features High

Where to next

Section titled “Where to next”