Introduction

Microfrontends are one of those architectural ideas that sound incredible on a whiteboard and occasionally feel like a bad life choice in production.

They promise a lot, And to be fair, they can deliver on many counts.

But they also come with real costs. At some point, you realize that microfrontends don’t magically remove coordination problems. They just move them to different boundaries.

I’ve worked with microfrontends in real projects, mixing different technologies, dealing with Module Federation, and shipping features under real constraints. So this is my opinion on why microfrontends are powerful, why they’re painful, and why despite everything they’re sometimes still the right choice.

Why Microfrontends Exist (and Why They’re Still Around)

Microfrontends appeared because frontend applications started to hit the same scaling problems backend systems faced years ago.

When:

• Multiple teams work on the same frontend

• Release cycles start blocking each other

• The codebase grows faster than shared understanding

• “Just refactor it” stops being realistic

a single monolithic frontend becomes a bottleneck.

Microfrontends try to solve this by aligning technical boundaries with team boundaries. Each team owns a slice of the UI, can deploy independently, and can evolve at its own pace. In theory, this reduces friction and allows organizations to scale without rewriting everything every year.

That theory is mostly correct. The catch is what it costs to make it work.

The Power (When Microfrontends Work, They Really Work)

When I started with microfrontends two years ago, searching through Google, I couldn’t find much, just the basics to start your application with module federation and one Udemy course. I had the chance to set up the project from scratch with my team.

In our case, we had a React host application acting as the shell, built with Vite, loading multiple remote microfrontends via Module Federation. Most remotes were React-based, but one of them was Angular with Webpack. We wanted to explore Microfrontends and its challenges to the fullest.

Each microfrontend:

• Was owned by a separate team or domain

• Could be deployed independently

• Could evolve without forcing a coordinated release across the entire frontend

Teams weren’t blocked by each other’s release cycles anymore. If one micro app needed a hotfix, it had no effect on the rest of the app.

Even framework mixing , React hosting Angular, was manageable with the right boundaries. The shell didn’t care how a microfrontend was built, only what it exposed. That separation is one of the strongest arguments for microfrontends.

The Pain (This Is Where the Real Story Is)

When we thought of mixing things up, you’d think why change it if it works? But I would say, what’s life without challenges? And my team and I were up for it.

Build and Tooling Complexity

Module Federation is powerful, but it’s also unforgiving. Version mismatches, shared dependencies, and subtle config differences can break things.

Vite helped with build speed, but debugging why a remote failed to load at runtime often meant:

• Checking federation configs

• Verifying exposed modules

• Aligning shared dependency versions

Angular + React: It Works… Until It Doesn’t

Running Angular microfrontends inside a React shell is doable, but it comes with sharp edges:

• Bootstrapping Angular correctly

• Making sure styles don’t leak or clash

• Keeping bundle sizes under control

Shared UI and Theming

One unexpected pain point was design consistency. Sharing themes meant:

• Passing theme tokens across framework boundaries

• Syncing design decisions without a shared component library

• Accepting that “shared UI” is harder than “shared code”

Local Development Is Character Building

Local dev is where microfrontends test your patience.

Running multiple apps locally, keeping them in sync, mocking missing remotes, it’s all doable, but it’s never simple. Even with good tooling, onboarding a new developer takes more effort than in a monolith.

The Hidden Costs Nobody Warns You About

Some costs only show up after the architecture is already live:

• CI/CD pipelines multiply: each micro app needs its own build, deploy, and rollback strategy

• Observability becomes fragmented: debugging production issues across multiple frontends is harder than it sounds

• “Independent” teams still need alignment: APIs, shared events, auth, and UX flows

Microfrontends don’t remove complexity. They redistribute it.

Lessons Learned (What I’d Do Differently)

After working with this setup, a few lessons stand out:

• Share as little as possible. Every shared dependency is a future negotiation.

• Invest early in contracts (APIs, events, exposed interfaces).

• Anticipate future problems don’t just solve as you go.

• Mixing frameworks is fine, mixing responsibilities is not.

Most importantly: microfrontends amplify existing organizational structure. If the structure is unclear, the frontend will be too.

When Microfrontends Are Still Worth It

Despite all the pain, I’d still choose microfrontends again in the right context.

They make sense when:

• You have multiple teams working in parallel

• Ownership boundaries are clear

• Independent deployments are a real requirement

• The organization is willing to pay the complexity cost

They are not a good choice for:

• Small teams and simple projects, things can get overwehlming.

• High performance requirements, sometimes loading can take time

• Style consistency, with mixing technologies you need to think it through from the start.

Final Thoughts

I’ve read few articles calling microfrontends a scam and a waste of time. Some where very strong worded. However, I think that complexity can be managed and the first approach is what sets the stage for the future.

They’re powerful, painful, and when used intentionally still worth it.

The real challenge isn’t technical. It’s knowing when complexity is solving a problem and when it’s just showing off.

If you can answer that honestly, microfrontends can be an asset instead of a burden.