I was on an MFE team earlier this year. It was sold to higher-ups as being for both, but I think in most cases it's bad for both. IME, it was sold in terms of code code-reuse by providing things like shared navigation bars, shared authentication logic, etc.

My team, at least, did not have the necessary support structures in place to help others who wanted to maintain their own UI. I see this mostly when crossing framework/language boundaries (mixing React + Angular in a SPA, as it was in my case). They declare microfrontends, but then all the component libraries were all React-based anyways.

It just ended up being a mess of N deployment processes, N build systems, N storage buckets, zero standardization whatsoever, and mountains of technical debt, all without much benefit.

...but if you're all working in the same language/framework where that component/style-lock-in is acceptable, why would someone use a microfrontend to begin with? Can the organization not set up a single repository with different teams contributing to it? One deployment, one build system, one storage bucket, and standardization?

IMO CODEOWNERS is the original and best "microfrontend" solution for small-to-medium-sized teams working on a single product. If you have hundreds or thousands of engineers (think FAANG) working on a single experience that just HAS to be a SPA, then maybe you have the resources to build out those support structures and actually get MFEs to work on an organizational level.

In the vast majority of cases, however, I see it as a bandaid on an organizational problem that's eaten up because it's an interesting technical challenge for senior engineers to think about (someone made a great comment about "drawing the perfect box"), and because management thinks it's a cool trend with benefits they can grok.

In that sense, when the UI is a browser client UI, I'm immediately suspicious of such isolation plans.

When you're building server architectures, it's fine... You have more storage than every book ever published in the 1800s on each machine you're deploying to, you can afford to have microservice A depend on library set Q and microservice B depend on library set R and as long as the public-facing contract doesn't change, nobody cares. Your deployment infrastructure does something to get all those dependencies in place (possibly even something hugely inefficient) and you're happy.

Efficiency of deployment still matters for the client. It is not okay to be shipping four different date libraries because your client is an MFE and the different departments in your company can't agree on what core library to use. That scales in the reverse direction: you're paying for bandwidth (and your users for time waiting for your site to load) per user. It's waste you can feel.

Yes, I agree. Microfrontends can be very useful if a small team needs an app quickly the same day, but can't wait for 2 years for the central IT department to deliver the tool.