When it comes to microfrontends, the hype is real and so are the trade-offs. In this in-depth conversation, Anton An, Lead Frontend Engineer, shares his journey across several projects, transitioning from a monolithic frontend architecture to microfrontends. He discusses the real benefits, the hidden costs, and the complex decisions that come with scaling frontend applications in a high-load environment.
A New Kind of Architecture
“In projects I’ve led,” Anton explains, “we aimed to isolate each UI module so failures in one part couldn’t take down the whole app. Rather than bundling everything into one giant build, each microfrontend is packaged and deployed independently, often as its own Docker container or service process. That way, if an image slider crashes, the navigation menu stays up.” This is the vision microfrontends promise: fault-tolerant, independently deployable UI elements. But Anton warns: “It’s not that simple.”
The Rise in Demand
According to a 2020 ThoughtWorks study, 24 % of developers were already using microfrontends, and 37 % planned to adopt them soon. Developers are drawn to the architecture’s fault tolerance, ease of supporting legacy code alongside modern frameworks, and the potential for faster, parallelised release cycles. Anton first piloted microfrontends around 2019, after experiencing the drawbacks of a traditional monolithic setup.
Life Before Microfrontends
“In an early project,” Anton recalls, “our entire frontend lived in one codebase built with jQuery, Vanilla JS, and Backbone.js. Routing was centralised and convenient, and a single change could ripple across the whole UI. At first, it felt blazing-fast. But as we added features, compile times stretched, merge conflicts spiked, and simple tweaks led to unexpected regressions.”
Why Break the Monolith?
The team eventually hit a ceiling. Updating even one dependency could introduce obscure bugs. “You’d see new tools out there but couldn’t adopt them without risking the entire UX,” says Anton. “It became a blocker for product growth.”
Microfrontends: The Promise
What Anton and his teams hoped to gain from microfrontends:
- Autonomy – separate teams could develop and deploy modules without stepping on each other’s toes
- Speed – releases could happen independently, not gated by a global deployment window
- Flexibility – each module could use the tech stack best suited to its needs
How Hiveon Did It
Later, at fintech platform Hiveon, the engineering organisation refined these ideas into a hybrid approach. Rather than a full monolith or a fleet of completely siloed micro-repos, they:
- Established a shell application for shared services (authentication, navigation)
- Leveraged Webpack Module Federation to load modules on demand and share common dependencies (UI libraries, React)
- Ensured single-page-app behaviour without full page reloads
They evaluated alternatives like Single-SPA and plain iframes, but found them either too heavyweight or detrimental to user experience. “In our hybrid model,” Anton notes, “we combined the reliability and consistency of a unified codebase with the isolation and parallel deployment of microfrontends. It turned out to offer the best of both worlds.”
The Reality: Benefits and Challenges
With microfrontends in place, team autonomy and release cadence improved, but new challenges surfaced:
- Blurring of responsibilities: Shared features (e.g., global filters) often diverged between modules until extracted into standalone packages.
- Dependency synchronisation: Keeping versions of React, UI kits, and utility libraries aligned across teams became its own project.
- CI/CD complexity: Each module demanded its own build and deployment pipeline, amplifying integration overhead.
- Integration bugs: Components that worked in isolation sometimes failed when combined in the shell, prompting stronger end-to-end tests.
“The complexity didn’t vanish, it simply moved,” Anton reflects, “but at least it became explicit and manageable rather than hidden and explosive.”
The Hidden Costs
As microfrontends matured, more “second-wave” issues emerged:
- Inconsistent UX: Independent teams produced UI drift, mismatched spacings, animations, and typography.
- Performance overhead: Loading multiple bundles and shared dependencies on the first render was heavier than a single optimised monolith.
- Operational burden: Tracing errors, pinpointing module ownership, and rolling back faulty releases required advanced tooling.
“If I were starting today,” Anton warns, “I’d allocate time not just for code, but for governance: design systems, performance budgets, testing strategies, and observability from day one.”
Could Teams Go Back to Monoliths?
It happens. Anton shares that some teams, including parts of Hiveon’s organisation, eventually partially rolled back. “We started with each microfrontend in its own repo, CI, and deployment. Coordination fatigue set in, so we merged several related modules back into a shared repository with a unified pipeline.
It wasn’t a full monolith, but a streamlined hybrid that cost less and was easier to manage.” In other settings, shrinking teams or shifting priorities have led organisations to abandon microfrontends completely, reverting to a single-page application when the extra complexity no longer paid off.
“Sometimes, merging modules back into one repo is the most rational move,” Anton admits. “It may not be glamorous, but it matches reality.”
Final Thoughts
Anton’s journey shows that microfrontends aren’t a silver bullet. They can unlock true parallelism and resilience, but they introduce new layers of complexity that demand careful planning, tooling, and ongoing governance.
Before diving in, teams must ask: Why are we adopting microfrontends, and how will we manage the hidden costs? With a clear strategy and lessons learned from both monolithic and micro-architectures, it’s possible to harness the strengths of each just as Hiveon did with its hybrid approach.
