When not to use mountly

Pre-1.0 software earns trust by saying no. mountly is a small, opinionated runtime, not the answer to every code-splitting problem.

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 want a microfrontend control plane

mountly is an on-demand component runtime. It is not:

• A team-routing layer.
• A versioning or deployment coordinator across teams.
• A central runtime configuration plane.

If you need “team A ships the checkout, team B ships the catalogue, both deploy independently and runtime-route by URL”, use single-spa or a vendor MFE platform. mountly validates manifests and loads verticals. It does not coordinate deployments or resolve semver at runtime.

mountly is useful inside an MFE: a single team’s MFE bundle can use mountly to lazy-load its own widgets without ballooning its part of the page. Use it as the inner tool that loads one team’s widgets, with single-spa or a vendor platform as the outer control plane.

When mountly is the right call

The shape of a good fit:

• 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.

If three or more of those bullets describe your situation, mountly is the right tool.