[pandler]

We make heavy use of peer dependencies, so microfrontends rarely end up actually bundling their own dependencies. Build tools like rollup help with that.

It’s not a silver bullet and requires A bit of overhead. I’m interested too to hear how other people manage the problem.

[Etheryte]

That is true, however one of the main arguments for micro frontends is the freedom to use anything: one team can use React, the other Vue, one uses this table library, the other another. If you don't do that, micro frontends offer very little in benefit as far as I see. If you do do that, what you're left with is pretty much regular architecture, just in separate repos and harder to keep in sync.

[FlorianRappl]

Personally, I think this is a myth (https://blog.bitsrc.io/11-popular-misconceptions-about-micro...).

Most our projects where microfrontends have been actively demanded (and we did now quite a lot of them) did not come up due to use of multiple frameworks. Yes, it is possible to use multiple technologies, but quite often there is key technology in place anyway. E.g., one of our clients had a huge pattern library written in React and demanded all microfrontends to be written in React.

So why then microfrontends at all? Well, all parts are still independent from each other, i.e., independently developed and deployed. Our client has multiple teams and like that these teams can just work in their own pace using a few guiding principles that have been given by the solution architecture.