2 ms·
Using iframes, for most apps, usually brings more pain than benefits. If an app is partially build with React, Angular and/or other lib/frameworks, that is in
by mariopt 7y ago
Using iframes, for most apps, usually brings more pain than benefits.
If an app is partially build with React, Angular and/or other lib/frameworks, that is in itself a red flag. You might be dealing with legacy code while moving to a newer stack. Using the same lib/framework brings you less mental overhead and quicker development speed, developer onboard, etc. Unfortunately I worked in some places where this was a sad reality and it was never easy to fix simple bugs due to the lack of structure, architecture, code conventions, etc . A refactor is your best friend but good luck convincing the product owner that you need X amount of time to bring 0 new features to the business.
Downsides of Iframes:
1. For each iframe you use, you'll use more memory, more CPU, bandwidth, increased TTI, etc.
2. You'll have to deal with subdomains authentication
3. Data over fetching, each iframe fetch its own data without sharing with another iframe. Trying to cache this is a sure way to chaos.
3. Breaking an app into tiny packages might be overkill when compared to having a proper folder structure, specially for UI.
4. Now you have a Content Security Policy to maintain, it gets trickier over time.
5. You’ve N CI pipelines, some repos will be “forgotten“ -> older React/Angular versions, packages that never got updated because you don’t work in that repo/“microfront”.
6. More DevOps overhead
7. Forget about good UX and be welcome to the world of redirects -> a “microfront” that takes you to another “microfront”
In my experience, breaking the business logic into packages is great since the logic is self-contained with unit testing, etc but placing the UI components there will bring you the problem of not having atomic UI components. Now if you want to change a UI component in just 1 package, good luck trying to figure out which pages could be broken.
You’ve to be very careful on how you break your app into packages, it only takes 1 bad design decision to make the whole thing a nightmare to work on. Not to mention when you’ve packages that depend on other packages, you haven’t written anything about versioning which is critical.
It is much easier to look at page built with React/Angular where you can see the exact definition of the UI versus jumping between several packages to try to figure out where do things come from.
Put the UI components and pages in a single folder/package. If you something like StoryBook and create your package for UI components, even that brings some work to get right and maintain, you split these components into more than 1 package and you’ll be running in hell for simple changes.
Reduced mental overhead is a precious luxury I strongly value.
edit: formatting