[mrsharpoblunto]

While I can see some benefits in terms of deployment flexibility, this really seems like a case of prioritizing your organizational chart over the end user experience. Its already hard enough to optimize a large JavaScript SPA so that it runs well on mobile devices - are we really suggesting that its a good idea to ship a UI to users device containing N different versions of React, Angular, Redux etc. all built using different build tools/pipelines with the final UI cobbled together and have it give a comparable experience to a native application?

Micro services work on the backend because the its effectively hidden from the user - thier device hits and endpoint and gets a response. On the frontend its a different story, the users device has to download and execute all that duplicated code.

[ivan_gammel]

It does not have to be as you described. I used microfrontend approach in one of my previous projects, where multiple customers of my employer could use different sets of services. Service discovery and hypermedia API allowed to compose the UI based on microservices deployed to customer-specific environment. Mictofrontends naturally complemented backend architecture: their build configuration and technology stacks were standardized, JS code was served from the same CDN, so there was no performance impact on customer. On the contrary, modularity of UI allowed to serve only the components purchased by the customer and available to the current user, reducing the size of downloads.

[jypepin]

I don't love micro frontends, but having been in an org that grew very fast to dozens/hundreds of engineers working on FE stuff, Conway's law was definitely at work there.

You are definitely right, this really is a case of prioritising your org chart, but you often don't have the choice.

[shados]

> this really seems like a case of prioritizing your organizational chart over the end user experience

No. It's case of being able to give the user more things they want, with each individual ones being built faster and optimized for their specific tasks without having to worry about the others. This comes at the cost of optimization of the whole (local maxima vs global maxima.).

If your product is something like, let say, Slack (one specific app that does one thing with a lot of features), it's a horrible fit.

If your product is something more like G Suite (several completely distinct apps that are semi related under an umbrella), that is where it shines. Other situations are things like internal apps where being able to DO something (at low cost) is often the priority.

There's a lot of ways to mitigate the UX impact, but yes, it has a UX impact. Its a tradeoff. Let's not forget that if you free your org of some burdens, they end up with more time to solve other problems, so it's not completely at the expense of the user.

[ivan_gammel]

There will be almost no UX impact if the decision on what defines each microfrontend is UX-driven. For example, feed and stories in Instagram-like webapp can be microfrontends - UX defines the structure of the container app and UI integrations, but then they can evolve independently.

[mrsharpoblunto]

There will almost certainly be a UX impact in the form of performance though - the whole point of micro-frontends as I can see it is that it allows you to have different infra&dependencies in different parts of the UI. The only reason you'd want to do this is because you don't want to share the same infra&dependencies across the UI which inevitably leads to duplication of frontend infra.

e.g. if my whole app is React based, why do I need micro-frontends?, using them seems needlessly complex. It only seems relevant if for example I have a product where team A has a legacy jquery UI, team B wants to add a part of the UI built in Vue, and team C wants to build out some features using React - but in that case the user is now having to download 3x the JS infra code that they did before because none of the teams can agree on a shared stack.

Also this pattern would seem to make composability of the UI much more rigid and inflexible. In the IG example you mentioned, lets say stories and feed got built out using separate stacks with separate codebases and infra. Now lets say we want to add a saved stories unit to the profile page, or add some recent stories as a new unit in feed (real examples - I used to work at IG :)) If we were on a common stack like React, I could just re-use the React story reel component from the stories tray and drop it into the Profile page (& maybe tweak a few props). With a micro-frontend, I'd have to create a content area for the other team to put thier story unit, agree on what the expected interactions between the profile & story unit were going to be, agree on a contract etc. wait for the other team to adapt the story reel so it was usable in the new context, make sure they deploy the new version of thier story unit...

The only situation I can see a micro-frontend being beneficial is as a stopgap pattern while migrating legacy apps - it certainly doesn't seem like an ideal end-state to me.

[ivan_gammel]

I agree with you that the use case with different stacks is suboptimal and may make sense only in enterprise apps. For consumer apps the impact is indeed too high.

However, just like with microservices the main point is not about having different technology, but about having different lifecycle and deferring the component integration to deployment or even runtime.

[ptah]

>a case of prioritizing your organizational chart over the end user experience this seems to happen regardless: https://en.wikipedia.org/wiki/Conway%27s_law