Why we built JORVEL

The problem

Big frontends are built by many teams, but most React meta-frameworks assume one app, one deploy. When five teams share a codebase, a one-line change to the marketing page waits behind the checkout team's release. Module Federation fixes the deploy coupling — but raw MF is a webpack config, not a framework: you hand-roll routing, SSR, shared-dep contracts, security, and CI yourself.

JORVEL is the missing layer: federation-first conventions with the DX of Next/Remix. Teams own remotes, ship on their own cadence, and the host composes them at runtime — with typed contracts, a CI diff gate, and version-skew warnings keeping the seams honest.

Why runtime Module Federation

Build-time composition (Nx, module boundaries) still ships one artifact — a change anywhere rebuilds everything. Runtime federation loads each remote as an independent bundle from its own URL/CDN, so a remote deploys without touching the host. That's the whole point: independent deployability. We build on Rspack because its webpack-compatible ModuleFederationPlugin is the only mature, fast path to it today.

What we deliberately left out (for now)

• RSC everywhere — the MF + RSC wire format isn't stable upstream. We ship islands, streaming SSR, use(promise), and hydratable server stores instead.
• A bundled backend/ORM lock-in — jorvel add db scaffolds Drizzle, but loaders/actions/server-routes are BYO-backend on purpose.
• A styling opinion — CSS Modules, Tailwind, and zero-runtime CSS-in-JS all work; we don't force one.