HyperFrontend started from a problem I kept running into with large frontend systems. Teams want to work independently, but the moment their applications need to live together, they get pulled back into shared frameworks, coordinated upgrades, shared builds, and release schedules. I tried the usual approaches. They work well when everyone can agree on the same assumptions. They become much harder when you have old applications, different stacks, separate teams, and software that cannot simply be rewritten. Eventually I went back to a much simpler boundary: the browser itself. HyperFrontend keeps each application as its own application, with its own deployment and technology choices. The host composes it and communicates through typed contracts, with lifecycle supervision, isolation, and optional encrypted messaging. A lot of the work since then has gone into the less glamorous parts: failure handling, security, tooling, compatibility, documentation, and proving the architecture through live demos. I’m putting it out there because I want to see how it holds up against real systems and real constraints. If you have an old frontend, mixed frameworks, independent teams, or a rewrite you really do not want to do, I’d be particularly interested in what you make of it.

HyperFrontend

Compose any web app, however old, without a rewrite

Compose any web app, however old, without a rewrite