Microfrontends: When They Make Sense (And When They Don't)

Microfrontends are the most over-applied architecture pattern in frontend engineering. Teams adopt them because they sound modern, not because they solve a real problem. Let me be direct about when they work and when they're just distributed complexity.

The Real Problem Microfrontends Solve

Microfrontends solve organizational scaling, not technical scaling. If you have 3+ autonomous teams that need to ship independently to the same user-facing application, microfrontends let them deploy without coordinating releases.

That's it. If you don't have this problem, you don't need microfrontends.

Module Federation (Webpack 5 / Vite)

Module Federation lets independently built applications share code at runtime. Team A's header component loads directly into Team B's shell app — no npm publish cycle, no monorepo required.

// webpack.config.js — exposing a component
new ModuleFederationPlugin({
  name: 'header',
  filename: 'remoteEntry.js',
  exposes: {
    './Header': './src/Header',
  },
  shared: ['react', 'react-dom'],
})

The catch: shared dependency versioning is a nightmare. If Team A uses React 18.2 and Team B uses 18.3, you get subtle runtime bugs that are painful to debug.

Single-SPA

Single-SPA orchestrates multiple framework apps (React, Svelte, Vue) into one page. It handles mounting/unmounting as the user navigates. This is useful if you're migrating from an older framework incrementally.

The reality: I've never seen a single-SPA project that didn't eventually consolidate to one framework. The migration is the use case, not the steady state.

When NOT to Use Microfrontends

• Your team is < 15 engineers — just use a monorepo
• You want code reuse — use a shared component library instead
• You want "modern architecture" — this isn't a valid reason
• Performance — microfrontends always add overhead, never reduce it

My Recommendation

Start with a monorepo (Turborepo or Nx). Only graduate to microfrontends when you have genuinely autonomous teams with different release cadences. Even then, consider if a well-structured monorepo with independent deploy pipelines per package would solve the same problem with less complexity.