Micro front ends: Right architecture, wrong place

The Good Idea: Apply microservice-style decoupling to the front end, allowing large organizations to increase agility by spreading the development of different UI features across different teams.

Breaking the monolithic UI into separate, smaller components that could be developed, tested, and deployed independently promised the same benefits as microservices did on the server side: autonomous teams, smaller codebases, easier maintenance, incremental updates. We could all work freer and move faster. But what about the poor end-user?

The Fatal Flaw: We took a distributed back-end pattern and forcibly applied it to the browser. It didn’t really make sense. Micro front ends solved an organizational problem, but created complexity, massive overhead, and performance issues on the end-user’s device. Instead of a cohesive application, teams ended up shipping multiple JavaScript bundles, duplicate dependencies, and occasionally entirely competing versions of UI frameworks onto the same page. The browser was forced to act as a distributed systems arbiter, leading to fragmented states, performance degradation, and meta-complexity.