When not to use mountly

A tool earns trust by naming its edges. mountly is a small, opinionated runtime for on-intent activation across hosts it does not own — three situations fall outside that.

You have a single SPA where the bundler owns every surface

If your project is one React, Next, or Svelte app and every component lives inside the same bundle, framework-native lazy routes are simpler:

// React example — already has on-demand loading via React.lazy + Suspense
const PaymentBreakdown = lazy(() => import("./PaymentBreakdown"));

You’d be adding a second runtime to solve a problem the framework already solves. mountly’s value is on-intent activation across heterogeneous hosts: static HTML, CMS pages, plain modules. That value compounds when the host doesn’t own a bundler.

If your situation is “I want a button that lazy-loads a modal in my Next app”, use next/dynamic or React.lazy.

You need SSR plus hydration

mountly mounts widget modules on demand, in light DOM by default and in a shadow root when shadow: true. It is not a hydration runtime.

If you need:

• Server-rendered HTML to be sent on first paint, then made interactive.
• The same component tree to work on the server and client.
• Astro / Next / Remix island patterns.

…use those frameworks’ islands. mountly mounts widgets after the page is interactive; it doesn’t take over server-rendered HTML.

The two layers coexist well: Astro, Next, Remix, or SvelteKit render the shell, routes, and server content, while mountly handles a portable widget that needs custom-tag placement, on-demand activation, or a separate component release path. mountly composes with those frameworks, but it does not replace their hydration story.

You need deployment orchestration

mountly can compose microfrontends with separate deployments. It loads modules, validates manifests, mounts features, and handles their browser lifecycle.

createFeatureRouter maps URL segments to features, and each vertical can route below its segment. Your release system remains responsible for semver policy, staged rollouts, and releases that must move together. If you need those controls inside the browser composition layer itself, use single-spa or a vendor MFE platform.

mountly can serve as the full browser composition layer, or sit inside a route-level MFE to load one team’s widgets. The release controls and routing model you need decide which.

When mountly fits

• You ship widgets that drop into hosts you don’t fully control.
• You need framework components to be addressable from HTML.
• You want one runtime + one cache story across all of them.
• You want intent-based loading without writing a new lazy-loader for every button.
• You want style isolation between the host page and the component.
• You want declarative HTML usage (<signup-card> or <mountly-feature>) for non-app teams to drop into pages.

Cross-host delivery and separate component release paths provide the strongest reasons to add mountly.