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

[AhtiAhde]

This would be an important topic I guess. There are some JavaScript libraries, which do not allow multiple instances of themselves (like babel-polyfill).

How should we properly manage the dependencies, while maintaining a strong separation of concerns for Microservice teams? Building only one bundle could be a solution, but it might have side effects of which the too large size would perhaps be the least severe.

We are just experimenting with this now and trying to set this up (and in many ways we are at heavy "Under Construction"-phase). There might be some easy and clever ways, but since you didn't cover this so far, I would be very interested in your answer. Should there be a distinction of global libs and microservice specific libs? And of course, something which is not global, might still have two instances within different microservices.

[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.

[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.

[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