Hacker News new | past | comments | ask | show | jobs | submit login

We're doing something like that for Klarna Checkout (https://www.klarna.com/us/business/sell-online-with-klarna). At first, we built applications as completely standalone applications that were loaded into iframes and communicated over postmessage. We're still doing that for some things, but it has some big drawbacks, especially when it comes to bundle size and browser support. Bundle size is pretty obvious, since you end up sending the same libraries multiple times, and since the applications are separated, you can't extract common dependencies at build time. As for browser support, you basically cannot nest more than two levels of iframes (parent -> iframe -> iframe), or all hell breaks loose. If any nested frame needs to be able to scroll or has form fields, prepare for pain.

What we're testing out now is distributing the "applications" as blackbox React components which are built into the consuming applications. The state of the applications is contained completely within the component, and the API is just exposed through props. It increases the coupling between applications, since it forces everyone to use React and even be on more or less the same version of React, but that was already the case for us, so it seems like an okay tradeoff. One downside is obviously that the consuming application grows larger and larger as we add applications to it, but that can probably be solved by asynchronously loading chunks on demand.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact