There've been some surprisingly incorrect assumptions being made about "microfrontends" since it became a buzzword. Microservices in the browser (I prefer this term over microfrontends) are a totally new paradigm but these bad takes seem to have quite a bit of reach. I'll tackle some of these in this post.
Chris Coyier, https://css-tricks.com/micro-frontends/
This is actually a huge mischaracterization. Think about this for backend services. Each app or service is independent so they can use a different framework or language. One service can be Ruby+Rails and another use Elixir+Phoenix. But in practice most companies should and will avoid this, it doesn't make sense to use any and every language or framework! No different here. Standardizing on few languages/frameworks makes total sense.
Your [developers] were so preoccupied with whether or not they could, they didn’t stop to think if they should.
Just because it can be done, does not mean it should or needs to be done. Most if not all of your apps should use a common set of frameworks and libraries. But realize that this possibility of using a different framework without high development costs and effort actually unlocks benefits, such as easy migration and experimentation. I find that to be super cool! Let me paint those scenarios.
At some point in every company's life, there comes a point where the decision to use Technology X that was made Y number of years ago no longer holds up. The maintainers do not see an easy way to move off of it, they're stuck. Being able to break free of and avoid technological lock-in is yet another major benefit of microservices in the browser. Using a front-end microservices architecture, you can begin migrating parts of the application to newer technologies and frameworks as each team or product is ready and able (the performance implications will be discussed below).
Maybe Technology X is not quite that old, but your developers see new trends on the horizon and want to get ahead of the curve. Or maybe a webapp has grown bloated and is a performance bottleneck and you would like to try out a newer, faster framework (something like Svelte maybe). This sort of experimentation could allow products, user experiences, and DX to improve as technologies evolve and advance. These upgrades shouldn't require months and years!
The answer to Dan's question here is yes. This can be considered "microfrontends" as each root can be owned by a single team. Though Dan later points out that this all is still part of the same CD pipeline and so each team is at the mercy of that process. Significant effort and investment would need to be spent to optimize this build system. But like backend microservices, microservices in the browser can enable independent deployments for front-end applications. Each team can have control over this, scaling to however fast or slow that needs to be for them. I don't think you could achieve that with multiple React roots.
Someone let me perf. profile a site using "microfrontends".— Sean Larkin (廖肖恩) (@TheLarkInn) June 13, 2019
Memebait related: pic.twitter.com/LMldrx14Ui
I have to ask: is application bloat a unique characteristic of microfrontends? I know of many frontend applications that are extremely heavy that are not microfrontends, which is mostly due to misconfiguration of tooling or extra package code. So is this criticism that implicitly claims that microservices are bloated by default, valid?
The underlying assumption here is that microfrontends disregard performance in favor of DX. Additionally, it's true that 2 is greater than 1; shipping multiple framework runtimes without prudence and care is going to be bad. But I'd argue though that that bad performance comes down to implementation, not architecture.
Back end devs: Front end isn't real engineering.— Mark Dalgleish (@markdalgleish) July 14, 2019
Front end devs: *Bring engineering principles to front end*
Back end devs: Front end is too complicated.
Give an emerging pattern like microservices in the browser a chance. Don't buck against it just because it isn't the way you've done things, and let go of your bad assumptions.