Esmx: a micro-frontend framework that skips the sandbox

The claim is that the browser already does the sandboxing

Esmx is described as a next-generation micro-frontend framework based on ESM, sandbox-free with zero runtime overhead, supporting multi-framework hybrid development.

The mechanism is native ESM plus an import map. The readme contrasts that with traditional solutions in a table, and the differences are all architectural. Where a traditional micro-frontend setup uses a manual sandbox plus proxy, Esmx uses native ESM. Where the traditional approach has runtime overhead, Esmx has zero. Where the traditional approach asks you to learn framework APIs, Esmx uses standard syntax. And where the traditional approach simulates module isolation, Esmx relies on browser native isolation.

That last row is the whole argument. The isolation that a sandbox framework has to build and maintain is, in the browser, a property of the module system itself. A module cannot reach into another module's scope, and an import map is how the browser resolves what a bare specifier means. If you use those two things, you get isolation and deduplication without writing a proxy.

The other claimed advantages follow from the same source. Zero runtime overhead means there is no client-side framework sitting in the page doing the linking, and complete SSR support with high performance and SEO friendly output is listed as a core feature rather than an afterthought.

The project is TypeScript, MIT licensed, and the homepage is esmx.dev with a guide at esmx.dev/guide/start/getting-started.html. The last push was on 2026-08-13.

Sixteen packages, all of them still in preview

The package table in the readme is the most informative part of the project page, because it shows how wide the surface is and, more importantly, how young it is.

Every single entry carries the same status, Preview. The set covers @esmx/core, described as the micro-frontend framework with ESM linking, @esmx/router as a framework-agnostic router, @esmx/router-vue for Vue 2.7 and 3, @esmx/router-react for React 18 and up, @esmx/import for import map utilities, and @esmx/pkg-wrapper for CJS and ESM named-export wrappers for federation entries.

Then there are the build tool integrations, and they follow a strict pattern. A framework-agnostic tool, @esmx/rspack, @esmx/rsbuild and @esmx/vite, plus a Vue and a React variant of each: @esmx/rspack-vue, @esmx/rspack-react, @esmx/rsbuild-vue, @esmx/rsbuild-react, @esmx/vite-vue and @esmx/vite-react. The core package list says the supported frameworks are Vue, React, Preact, Solid and more, and the build tools are Rspack, Rsbuild or Vite.

That nine package build integration matrix is the practical cost of framework-agnosticism, and it is worth understanding before you commit. Each build tool needs its own integration layer, so a project on Vite and React installs one package, while a monorepo running three tools and two frameworks installs five.

The releases are v3.0.0-rc.123 from 2026-07-29, v3.0.0-rc.118 from 2026-06-18 and v3.0.0-rc.117 from 2026-04-27. A release candidate with a revision counter in the 120s is a project iterating quickly on an unstable API, which is consistent with the preview labels.

The scaffolding tool is create-esmx, described as the project scaffolding tool, and the getting started command is a single line.

Getting a project running, and what the monorepo expects

The getting started path is one command:

npx create-esmx@latest my-app

Beyond that, the readme points at the documentation rather than expanding the steps, so the detail has to come from the guide site. That is normal for a framework of this size, but it means the README is a map rather than a tutorial.

The repository is a Lerna and pnpm monorepo, and the root package.json shows the shape. The workspaces are packages/* and examples/*, the type is module, and the build is a Node script rather than a task runner chain, with build running node ./build.mjs, build:packages and build:examples filtering by path, and a separate build:dts step for declaration files in the micro-app example.

The engines field requires Node 24 or later and pnpm 10 or later, which is worth noting because it rules out some CI images without a version bump. The scripts show a fairly complete quality setup: Biome for JavaScript linting and formatting, Playwright for visual tests with a snapshot update variant, a smoke script, a release script, a validate-llms script, a gate5 script and a highlight-snippets script. There is a lighthouserc.json, a husky directory with lint-staged and a .lintstagedrc.js, and a biome.json.

For development, the readme says to run pnpm build first to build all packages and examples, then move into the specific project directory to start development. The examples directory is where the interesting cases live: a docs example, a micro-app example, and then SSR examples for rsbuild and vite across html, react and vue, so six SSR combinations plus the micro-app example.

What ESM linking actually gives you, and what it does not

It is worth being precise about the mechanism, because the word sandbox carries a lot of weight in micro-frontend discussions and the two are not the same thing.

A sandbox in the traditional sense is a mechanism that gives a remote application a restricted environment, often with a proxied object graph so that a guest can only reach a whitelisted set of host APIs. It is a compatibility layer: the guest expects to run in a browser but is really running inside a host-controlled runtime that mediates access.

Esmx does not build that. The applications run as native ES modules in the page, and the browser provides the isolation, because ES module scopes are separate and imports are explicit. The import map, handled by @esmx/import, is the part that resolves which file a given specifier points at.

The consequence is that there is no host API surface to expose. A guest cannot call host functions, because there is no proxy to mediate such a call. Communication between applications has to happen through something the browser itself supports, which means events, shared storage or a direct import of a shared module. That is a genuine constraint on how you design cross-application collaboration, and it is a different constraint from the sandbox one.

The second consequence is the deduplication. Because the browser resolves modules, two applications that depend on the same library can share one instance if the import map points them at the same URL. In a proxied setup each guest typically has its own copy, and version conflicts are a classic source of bugs.

The third is that this is a browser-native assumption. Import maps and native ESM are a modern browser feature set. The approach does not extend to an old browser environment, and it does not by itself solve the server side of the story, which is why the SSR examples are separate projects in the examples directory rather than a mode of the same one.

Where the build tooling fits, and the CJS problem it still has to solve

Two of the packages are there because of problems that ESM alone does not solve, and they are worth understanding as a pair.

The first is the build layer. Rspack, Rsbuild and Vite each get a framework-agnostic tool plus Vue and React variants, and the readme describes the builds as significantly faster. The reason each build tool needs its own integration is that each has its own configuration model and its own plugin API, so a framework-agnostic micro-frontend layer still has to speak each of them. That is the pragmatic cost of supporting three popular bundlers rather than picking one.

The second is @esmx/pkg-wrapper, described as providing CJS and ESM named-export wrappers for federation entries. The problem it addresses is that a large part of the JavaScript ecosystem is still CommonJS, and a CommonJS module does not fit naturally into a native ESM graph, particularly when the consumer needs named exports rather than a default export.

Wrapping is the approach: you take a CommonJS dependency and produce something the ESM graph can import with the named exports the micro-frontend code expects. This is the sort of compatibility detail that is invisible when it works and painful when it does not, and having it in a dedicated package rather than scattered across integrations is a reasonable sign of how the project is structured.

The router packages are the other half of the story. @esmx/router is framework-agnostic, with Vue and React integrations on top, and the repository topics list both react-router and vue-router, which suggests the framework-specific packages wrap those rather than reimplement routing. In a micro-frontend setup the router is where the host and the guests have to agree about URLs, and having one router implementation with thin framework adapters is a reasonable shape for that.

The main open question for an adopter is how much of the host page the framework expects to own. The readme does not answer it, so that is something to confirm in the documentation before committing.

Editorial conclusion

Adopt Esmx if your organisation has independently deployed frontends on different frameworks that now need to live in one page, and you want isolation from the browser module system rather than from a JavaScript sandbox you have to maintain. Do not adopt it if you need a stable release, because every package is listed at preview status and the recent releases are v3.0.0 release candidates, and do not adopt it if your host page is not a modern browser, since the whole approach depends on import map support. Before you commit, run the create-esmx scaffolding command, try the micro-app example, and confirm that the import map strategy in @esmx/import matches how your existing apps are built.

Frequently asked questions

Official sources

1. esmnext/esmx on GitHub
2. License: MIT
3. Project website
4. README
5. Releases