When not to use mountly

Skip Mountly when the host already owns the problem.

One app, one bundler

If every component lives in one React, Next, or Svelte app, use that framework’s lazy routes:

const PaymentBreakdown = lazy(() => import("./PaymentBreakdown"));

A second runtime does not help here. Mountly earns its keep when the page is static HTML, a CMS template, or another team’s shell.

SSR and hydration

Mountly mounts after the page is interactive. It does not hydrate server-rendered HTML. For first-paint SSR plus hydration, use Astro, Next, Remix, or SvelteKit islands.

Those frameworks can still own the shell while Mountly delivers one portable widget that needs a custom tag or its own release path.

Staged rollouts and traffic splits

Mountly loads modules, validates manifests, and mounts features. Your release system still owns semver policy, staged rollouts, and releases that must move together. If you need those controls inside the browser composition layer, use a platform built for that.

createFeatureRouter maps URL segments to features when you want route-shaped composition without that orchestration layer.

When Mountly fits

• Framework components on a page you do not fully own
• HTML-addressable tags for CMS or partner teams
• Intent-based loading (viewport, click, idle) with a shared cache story
• Style isolation via shadow: true when the host’s CSS would fight you

More on the job: Positioning. More on release shapes: Choosing an architecture.