Hyperfrontend

Imagine a user opens a feature, switches to another section and then comes back later. I wonder how Hyperfrontend handles that feature in the background. For example can the host app decide when a feature should stay active or when it should be closed to save resources? Wishing you a successful launch!

Pressing Ctrl+C halfway through a CLI setup should not leave the terminal in a broken state or throw a random error. I've hit that issue a few times when building internal tools. The fact that a cancelled prompt just returns a normal result you can handle in one place, instead of "crashing the whole process" is a smart way to keep the terminal clean. Good luck guys (:! You are doing great work. Keep it up 💪.

Say a team releases a new version of its feature and something stops working. Can they roll back just that feature or would the whole app need to be rolled back too?

Hi @aria_bruce, ty for giving hyperfrontend a try! If you run into issues or anything is unclear, feel free to send me a message or raise it in the GitHub repo :)

Hi @Selina_c1c, thanks for checking hyperfrontend. Running two different apps locally in different ports/origins shouldn't pose a problem. Having that said, I'll include a quick guide in the docs-site. Can you share a bit more about your code setup?

Updating the host and feature at different times can cause connection problems if they use different protocol versions. I read the documentation on your site and it is really well written. Appreciate the effort you've put into explaining these things in detail.

I hate when a tool forces to rebuild a feature just because you want it to open in a modal instead of a standalone tab. plus point: the option to drop a Hyperfrontend feature directly into the page, a dialog or a separate window save extra work. Is switching between those modes something the host can choose at runtime or does each mode need separate setup?

Just set up my first feature shell with Hyperfrontend 🙂. The best part is definitely the incremental adoption. Instead of trying to rewrite the whole monolith at once, I can just isolate one specific view and swap it in. It turns a scary migration project into something I can actually tackle on a Tuesday afternoon.

We are blocked on the platform team" is easily the most annoying sentence in software engineering. Letting each team deploy their feature shell to its own origin and ship on their own schedule completely removes that bottleneck.

Running two different apps on a laptop to test how they work together can sometimes cause CORS errors. I'd definitely try Hyperfrontend on a small feature first to see how it fits with our codebase. Lil question that came to mind: is there a simple way to test the host app and feature locally when they run on different origins?

Getting a TypeScript package ready for npm can take extra time especially when need both ESM and CommonJS versions. Happy to see Hyperfrontend Builder handle the build files and types through a single config file instead of making developers manage everything separately. That means less manual work when getting a package ready to publish. Hope the launch brings good early users.

I never feel good about raw postMessage across different origins. Hyperfrontend handles origin/target validation and packet obfuscation with rotating keys right down in the network-protocol package, which is exactly where it belongs. Building that low-level security layer from scratch is too painful so most teams skip it entirely.

Stefano Pompei, thank you! Glad you liked the video, had a lot of fun putting that together :)

Brandon Ellis, yes! Each embedded app runs in its own iframe with its own dependencies, so teams can use different library versions without clashing.

When different frontend apps use different versions of the same library, does Hyperfrontend help avoid dependency conflicts between them?

Raw postMessage across iframes usually a nightmare cuz one team adds a new field and the other team's app just silently breaks. Having typed contracts helps a lot with this. Hyperfrontend is really a great product that solves a real problem for frontend teams. Best of luck with the launch :)

Pitching a six-month full frontend rewrite to management is almost impossible because they never want to pause new features. It's great that Hyperfrontend lets you just carve out one specific section (like a legacy billing page), rebuild it in a new framework and slot it in via an iframe while the rest of the old app keeps running as usual.

Congrats on the launch! If one team builds a feature in Vue and the main app uses React can we add that feature without making big changes to the existing app?

Very interesting, good luck! And... chapeau for the video!