Monoliths to Microfrontends Should You Split Your UI?

From Monoliths to Microfrontends: Should You Split Your UI?

Frontend development has come a long way from jQuery spaghetti and template-driven pages. In today’s ecosystem of single-page apps, modular design systems, and globally distributed teams, one question is becoming increasingly relevant:

Should we break up our frontend into microfrontends?

Let’s unpack that.

The Monolith Era: One App to Rule Them All

Traditionally, frontend teams build and ship one large, unified application. This “monolith” is simple to deploy, straightforward to test, and familiar to most developers.

But as apps grow in size and complexity, the cracks start to show:

• Long build times
• Risky deployments (a tiny change can break the whole app)
• Scaling the dev team becomes harder
• Codebase coupling leads to tech debt

Sound familiar? That’s where microfrontends come in.

What Are Microfrontends?

Microfrontends apply the microservices philosophy to the frontend.

Instead of one large app, your UI is broken into smaller, independently developed, tested, and deployed frontend modules.

Each team owns its piece of the UI, end to end: code, deployment, and even infrastructure.

Imagine this:

• The cart team owns /cart
• The search team owns /search
• The user profile team owns /account

Each part of your UI can now be built and shipped without waiting on the others.

When Microfrontends Make Sense

You don’t always need microfrontends. But they shine in:

1. Large-scale applications: Enterprise apps with dozens of teams and domains. 2. Polyglot tech stacks: Teams want to use different frameworks (e.g., React + Vue in one app). 3. Independent deployments: Teams need autonomy to ship fast. 4. Legacy upgrades: Gradually modernize without rewriting the whole frontend.

But hold up. There are trade-offs.

When to Stick With a Monolith

1. Small teams: Microfrontends add complexity. Not worth it unless you need the separation. 2. Uniform stack: If everyone uses React and ships together, it might be overkill. 3. MVPs: Start simple, scale later.

Use microfrontends to solve real problems — not just because it’s trendy.

How to Build Microfrontends (with Examples)

Option 1: Module Federation (Webpack 5)

Module Federation is the shiny new tool for building microfrontends. It lets apps dynamically load code from each other at runtime.

Example:

// In host app's webpack config
new ModuleFederationPlugin({
  name: 'host',
  remotes: {
    cart: 'cart@https://cart.example.com/remoteEntry.js',
  }
});

// Usage in code
import Cart from 'cart/CartApp';

Each team builds their own remote module and exposes it via Webpack. At runtime, the host app pulls in that code from a remote URL.

Option 2: Single-SPA

Single-SPA is a microfrontend orchestration framework. It lets you register multiple apps (React, Vue, Angular) and mount them based on routing.

Example:

registerApplication({
  name: 'navbar',
  app: () => System.import('navbar'),
  activeWhen: ['/']
});

registerApplication({
  name: 'checkout',
  app: () => System.import('checkout'),
  activeWhen: ['/checkout']
});

start();

Think of Single-SPA as the traffic cop for your frontend micro-apps.

Option 3: iFrames (Yes, really)

Still valid in some cases! Especially when the microfrontend is truly isolated or hosted on a different domain for security reasons.

Pros and Cons

Real-World Examples

• Spotify: Uses microfrontends for different parts of its web player
• Zalando: Early adopter, powering entire shopping flows with microfrontends
• DAZN: Built a video streaming app using a microfrontend architecture

Final Thoughts: Split with Purpose

Microfrontends are not a silver bullet. But they can be a powerful tool in the right context.

Start simple. If you’re a small team or building something new, a well-structured monolith might be best.

But if you’re hitting scaling limits — team bottlenecks, slow builds, or deployment drama — it might be time to split the frontend.

Don’t split because it’s cool. Split because it makes your team faster.