A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] New IFrame related features to foster large scale Micro Frontend solutions


TL;DR: To evolve IFrame or create something to foster large scale real micro frontends applications with DOM and JS isolation. Web standards are lacking capabilities to allow the development of such kind of architecture.

Background Context

I have been researching a good solution for implementing micro frontends, that could really comply with some criteria needed to make it work into large scale projects.

11 years ago I helped to create a complex Web app ecosystem inside a brazilian bank (Banco do Brasil [www.bb.com.br], ~65MM customers). That solution has similarities to what is now called Micro Frontends, since it consists of ~600 different web context applications, implemented and deployed independently by ~300 different teams. It’s something used daily by 90.000 employees with a peak of 70.000 simultaneous.

This architecture allowed it to thrive and scale up to this level, but it has some fundamental principles that are different from what I see that have been done to do for Micro Frontends.

The main difference was DOM and JS isolation achieved by the usage of IFrames. Every single person that talks about IFrame, starts by saying to avoid it. But the IFrame provided me at that time, and still do, the level of isolation needed in such a large scale and chaotic environment. By using IFrame we are able to:

  • Avoid that a micro frontend mess up with the main DOM
  • Monitor and Recycle miss behaving micro frontends
  • Do some “memory management” by removing the no longer needed micro frontend, having the certainty that that application did not hook up anything to the main DOM.
  • Having the micro frontends broadcasting events to others through browsers, allowing client side interaction with low coupling. In order to do that I had a main page web app that acted as a client side app manager (at that time we didn’t have the Broadcast Interface). Today it’s like a App Shell concept from PWA, but instead of having a content section with html, we use IFrames to manage it and “run” the app into a sandbox.

What’s the lack of this capability is resulting into community

In order to really have micro frontends, we must have Runtime isolation, as we should seek for apps independence from each other, as we do it into server side microservices. We need to prevent dev teams from stumbling into another in runtime.

The current Micro Frontends that I got to know until now, use creative solutions to fuse the apps at the same DOM, losing the runtime independence at the client side. It’s literally like being running microservices as a process inside the same VM or even worse, the same application server and saying they are isolated just because they can have independent deliveries.

Why something new is needed?

So, why am I looking for a better solution? Well, IFrames doesn’t solve the problem completely. Today all the apps run under the same domain, so guess what? The micro frontends devs are creative and began to slightly manipulate the main DOM (App Shell), outside its IFrame and to hookup listeners where they shouldn’t do. They even manipulate others micro frontend’s IFrame! Remember that we are talking about thousands of devs trying to do their work.

In order to reverse that level of freedom I thought about using different domains for each micro frontend, shifting to the cross domain. But this is impossible, because that due to XSS protection, the main page app can’t have any level of control over the IFrame (that would be a security flaw) and I would end up relying into a bunch of unneeded cross origin postMessage usage and end up by coupling the micro frontend into the main app “communication protocol”.

I’ve tried to use the sandbox attribute but it doesn’t meet the requirements, I can elaborate more about it also if needed.

Next steps??

I would like to work into a proposition to evolve the IFrame, in such a way that could be possible to have real micro frontends apps. The idea is to do that without break backwards compatibility. By creating visibility scopes for DOM sections and JS run time between IFrames.

A see many solutions that need to scale web development to hundreds of teams to struggle with these kinds of problems. As another reference see the tips from Pega Platform to avoid memory leak into the browser side: Common JavaScript memory leak patterns | Pega This is totaly error prone

So first of all I would like to know if I’m missing something. Could you suggest any further work/research/step, in order to improve my understanding or to start something? Should I try to make a PoC with an open source browser? Or what I’ve written here doesn’t make any sense at all? In such a case what are the directions for me to evolve with this proposal?


I would love to see this feature, I have been thinking a lot about something similar in the past year and I already made some research online.

Probably a similar proposal are HTML includes that are already being discussed.


Thanks @collimarco for pointing me to this discussion!

I read the history (a lot of discussion going on there) and I see there is a plenty related work and discussion as:

I got the impression that all these topics are trying to create a means to reuse HTML or web fragments between files, projects and so. So the main focus is re-usability.

I read the comment you linked here also (referring to the “Client side include feature for HTML”, when you mentioned the scoped CSS and JS. I guess you are referring to something like the [css-scoping] Please bring back scoped styles discussion that was pointed. Am I guessing right?

Well, I didn’t read any deeper into css-scoping discussion, to say anything about it. From all links here, the css-scoping one seems to be into a similar (not the same) path to what I’m proposing., but with a narrow scope, restricted to css.

But I think you got the point of what I’m proposing. It’s about in scope execution or runtime isolation that I’m seeking to achieve, even for from the same domain as I’ve written about it above, we need some improvements.

So while these works are seeking for re-usability, I’m trying to achieve interoperability improvements with proper decoupling.

When we implemented a micro frontend like architecture we gave the freedom to the developers, that was the main benefit that I’ve seen. We have a very few but powerful reuse; mainly because reuse means coupling, that means less freedom (even with IFrame’s runtime isolation).