How about JavaScript bundles, which only allow one instance of themselves to be run? about micro-frontends

[naltatis]

Polyfills are in deed a little bit tricky. We are using two different approaches here. The first one is conditional execution. So every team ships the polyfills they need, but does not run the polyfill code when it detects its already present. Nice thing here is that fragments don't depend on their environment and are truely self contained.

The other option we are acutally using is to have a set of common polyfills that all teams agree on (like fetch, Promise, Symbol, ...) and include it globally for browsers that need it. This inclusion is done by the owner of the page. The actual polyfill-file is located in a shared repository. I think this globally shared code is fine when you talk about polyfills, because well written polyfills are not subject to change and incompatibility. Wouldn't do this with custom libraries though.

Do you have another concrete example of a library that only allows one instance?

When talking about bigger dependencies like react we leverage webpacks dll feature to avoid duplicate downloads while maintaining the ability to use different versions side by side when needed. We wrap libraries like this in a webpack dll package and provide a central url where the actual bundle can be downloaded from in the browser. This works, but you should be aware that the dll format depends on the webpack version it was built with.

When all browsers support js modules and import() the same thing could be done nativly.

[GrosSacASac]

One thing to keep an eye on is html modules proposal, which could help create the composition team to compose all the micro frontends together WICG/webcomponents#645

[pedrotcaraujo]

Is it right to claim that with this approach the user will need to download all of the frameworks/libs used by fragments? How did you balance the UX/DX to make this decision?

Micro-frontend makes sense for me on the DX side. I just would like to understand on the UX side. What were the costs of it?

[naltatis]

As always it depends on how you implement it. I'll write more in depth about "performance" in the future, but in essance it boils down to "keeping it simple, only include dependencies you really need" and "beeing smart about lazy loading code".

Yes, the micro frontend approach focusses on maintaining high velocity in development by dividing a big application into smaller, easier to maintain parts. So that you don't end up with a big ball of mud nobody understands anymore and is afraid to refactor.