This shouldn’t be a spicy take but I strongly believe micro-frontends are an anti-pattern.
It’s a warning sign within an private company. Micro-frontends are this concept where a single page or different parts of a website loads multiple different, competing Frontend frameworks or technologies. The idea has been adapted from Backend architecture. It might be a symptom of a CTO that devalues Frontend or hasn’t been given enough authority.
So, the homepage of a website might have the menu built in React while the Content is being served in Vue and the footer in Angular.
The inability to choose a stack
This isn’t desirable; it is a symptom of organisational issue. This is a political problem not a technical one. Seemingly no-one in the organisation has enough power or expertise to choose and enforce a stack choice.
What might happen in an organisation is that Development teams are split similarly to how the organisation is structured. If one team is responsible for a Blog, this gets built in one stack, the Checkout in another. No-one is in charge that can wield enough power to choose one stack or get teams to work together. This might even by Design, to “move at speed.”
As a result, a Development team that is isolated decides that they want to use a certain stack rather than integrate with what’s existing. This could be for a variety of reasons. They might choose a framework they’re used to it. It might be chosen as it’s popular, perceived to pay more or just something they want to learn.
In an ideal world a CTO should be able to enforce the stack choice. There is limited technical benefit of 2-5 competing technologies existing on the same website let alone the same page. Using Tailwind, PostCSS, Sass, LESS, Bootstrap, Foundation, LostGrid, React, Vue, Grunt, Webpack, Gulp all on the same project is a sign of a problem. Everything from Accessibility to Performance is negatively impacted.
Now what’s happened is someone has coined this mess and are somehow positioning it as an intended, desirable outcome. Each time I’ve seen micro-frontend suggested in a company there as usually a common set of patterns.
Outsourcing, this is a big one. How does a 3rd party deliver a feature when they’ve got to work with the existing team and stack? Easy; they don’t. This anti-pattern allows a section or feature of the site to be isolated and a new stack being chosen justified.
Devaluation of Design as a function, either there are no Designers or only one or two. The ratio of Design to Development is massively skewed.
Lots of “Fullstack” Developers but limited-to-no dedicated Frontend specialists. Having PostCSS, Tailwind and Sass on the same page would be flagged by Frontend - “why don’t we just choose one and stick to it?”
Refusal to acknowledge or resolve organisation problems, instead the solution is more tech - more tooling, more frameworks.
Poor communication and collaboration across departments, teams have siloed themselves and their work is isolated. This is perceived to be easier as teams can deliver their features without interaction but as a result common UI elements are being built (and loaded) multiple times.
Common code is not shared. The button on the homepage has completely different code to the button on another part of the site. This doesn’t happen just once, it happens 10-15 times in a single user journey.
Power - does anyone have the power to block or enforce stack choice? If not the exception becomes the norm.
Addressing some of the “benefits” in the article:
“Be Technology Agnostic. Each team should be able to choose and upgrade their stack without having to coordinate with other teams.”
Why should that be the case? People absolutely should coordinate with other teams, this is simply working together as an organisation. Instead of prioritising Developer Experience everyone at the company could simply use one stack.
If a button updates on the homepage how does this cascade to another part of the site that uses the same button? If a date-picker has already been built by one team, is this going to be built again?
“Isolate Team Code. Don’t share a runtime, even if all teams use the same framework. Build independent apps that are self contained. Don’t rely on shared state or global variables.”
This can be achieved without having to load competing technologies on the Frontend.
“Build a Resilient Site”
Micro-frontends are less resilient, each framework comes with hundreds of dependencies, all of which need to be monitored, updated and even deprecated. It adds a web of complexity and maintenance concerns. If you have three different JavaScript frameworks on one page, are you’re having to hire someone with expertise in all three.
This mirco-frontend “solution” is in part why Design System is often needed. A Design System is very much a solution to address this new problem that’s been introduced. Namely a fragmented, inconsistent Frontend stack.