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 — and 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 can coexist well: Astro, Next, Remix, or SvelteKit can 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. The boundary is important: mountly is composable with those frameworks, but it is not replacing 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 / deployment coordinator across teams.
• A central runtime configuration plane.
• A module-federation host.

If you need “team A ships the checkout, team B ships the catalogue, both deploy independently and runtime-route by URL”, use Module Federation, single-spa, or a vendor MFE platform. mountly will not protect you from runtime version skew or coordinate deployments.

mountly is useful inside an MFE: a single team’s MFE bundle can use mountly internally to lazy-load its own widgets without ballooning its part of the page. But mountly is the inner tool, not the outer one.

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 probably the right tool.