👋 Hey there, fellow developers! After months of deep research, hands-on coding, and countless discussions with Design System providers, I'm excited to share my findings on Micro Frontends in 2025 and how they integrate with Design Systems.
If you've ever struggled with scaling complex frontend applications, keeping teams aligned, or dealing with messy monoliths, Micro Frontends could be the solution. In my experience, they work best in large-scale applications, especially when paired with Domain-Driven Design (DDD). By breaking the frontend into self-contained micro-apps, teams gain autonomy, move faster, and scale more efficiently - all while developing deep domain expertise.

In this blog post, I'll walk you through:
✅ What Micro Frontends are and when to use them
✅ Different implementation approaches: Next.js Multi Zones, Single-Spa, Module Federation, Astro & SystemJS
✅ The importance of Design Systems and Design Tokens
✅ Why Web Components matter & why Stencil beats Lit in real-world

🚀 Let's get started!

🎯 What Are Micro Frontends & When Should You Use Them?

At its core, Micro Frontends extend the idea of Microservices to the frontend. Instead of a massive monolithic UI, you split your application into smaller, self-contained frontend modules that can be developed, deployed, and maintained independently.

When Do Micro Frontends Make Sense?

Micro Frontends shine in scenarios where:
You have multiple teams working on different parts of the UI.
You need to mix technologies (e.g., React, Vue, Svelte, Angular, Web Components).
You want independent deployments without touching the entire app.
Performance and scalability are key concerns.

By decoupling your frontend, you reduce complexity, improve team autonomy, and scale efficiently - all while avoiding the headaches of a bloated monolithic frontend.

🛠️ Approaches to Implementing Micro Frontends

There are several ways to implement Micro Frontends.
Here's a breakdown of the top approaches:

1️⃣ Next.js Multi Zones - Best for Performance (SSR) & Large-Scale Apps

Next.js Multi Zones allow different Next.js applications to function as separate "zones," making it easy to split the UI into independently deployable apps. But that's not all - Next.js Rewrites enable applications running on different servers or ports to be tunneled into the main app, acting like a reverse proxy. This not only avoids CORS issues but also allows seamless integration of independently hosted Micro Frontends.

// next.config.js
module.exports = {
  async rewrites() {
    return [
      { source: "/dashboard/:path*", destination: "https://dashboard.example.com/:path*" },
      { source: "/shop/:path*", destination: "https://shop.example.com/:path*" },
    ];
  },
};

✅ Pros: Full SSR support, acts as a proxy to avoid CORS issues
❌ Cons: Only possible with Next, React, Vanilla or web components. No support for Angular, Vue etc. Partial micro frontends are not natively supported and must be expanded if necessary.

Extending Next.js with SystemJS

To take this a step further, Next.js can be extended with SystemJS to enable client-side loading of partial Micro Frontends. This approach is great when you want dynamic runtime composition of Micro Frontends on the same page without page refreshing or separate routes (zones).

Server-Side Rendering (SSR) for Micro Frontends & Web Components

One of Next.js' biggest strengths is its SSR capabilities. This means:
Entire Micro Frontend applications can be pre-rendered server-side for better SEO and performance. Web Components (including Design Systems) can also be pre-rendered on the server, ensuring a seamless user experience.

By combining Next.js Multi Zones, SystemJS, and SSR, you get a highly scalable Micro Frontend architecture that balances performance, flexibility, and maintainability.

🔍 Example Integration

2️⃣ Single-Spa (Best for Multi-Framework Frontends)

Single-Spa enables different frontend frameworks (React, Vue, Angular) to coexist in a single application, making it a great choice when teams use different technologies.
Example:
✅ Pros: Supports multiple frontend frameworks, Allows teams to work independently, Good for client-side applications
❌ Cons: No built-in SSR support, Can lead to performance issues, Slightly outdated. TypeScript-Rewrite, ESM support is still in beta since September 30, 2024.

🚨 Single-Spa and SSR: A Mismatch?

SSR (Server Side Rendering) is not meant for Single-Spa. It's designed as a microservices architecture for client-side rendered applications. If you're building a server-rendered app, the server already handles routing, making Single-Spa's routing redundant. For applications with many Micro Frontends, the lack of SSR support can become a performance bottleneck. While there are SSR extensions like Single-Spa-Layout and Tailor, they require complex configurations and rely on UMD-compatible packages.

🔍 Example Integration

3️⃣ Webpack Module Federation

Webpack Module Federation enables dynamic runtime loading of remote modules, making it great for Micro Frontend composition. Like Single-Spa, it's mostly client-side, with SSR requiring extra effort, including a React Router and a custom Node server. However, bundling feels slow, and Next.js is moving away from Module Federation, favoring Multi Zones instead - making Module Federation less relevant for future Next.js projects.
✅ Pros: Native Webpack support, fast performance
❌ Cons: Can get complex with versioning issues

🔍 Example Integration

4️⃣ Astro (Best for Lightweight Frontends)

Astro is a server-first framework focused on ultra-fast frontend performance with a zero-JS approach by default. While it lacks true Micro Frontend support, it can still be used for that purpose. For partial Micro Frontends (e.g., embedding a React component for weather updates), Astro Islands provide a framework-independent solution. However, Astro doesn't support full app integration at the route level.
✅ Pros: Insanely fast, supports multiple frameworks
❌ Cons: Not ideal for highly interactive apps

🔍 Example Integration

5️⃣ SystemJS (Best for Low-Level Customization)

SystemJS enables dynamic ES module loading across apps, offering maximum flexibility. While not a full Micro Frontend solution, it's useful for small, partial integrations like a weather widget.
✅ Pros: Extremely flexible
❌ Cons: Requires extensive manual setup

🔍 Example Integration

🎨 Why Design Systems & Design Tokens Matter

A Design System is more than just a UI library - it's a centralized set of reusable components, design guidelines, and tokens that ensure consistency across your application. To develop UI components in isolation while documenting them simultaneously, Storybook is highly recommended for efficiency reasons.

What Are Design Tokens?

Design Tokens are digitized design decisions - platform-agnostic variables like colors, typography, and spacing that maintain visual consistency. With tools like Style Dictionary, you can convert them into any format you need. Design tokens are the foundation of a design system.
Example:

{
  "primary": "#FF5733",
  "font-size-base": "16px",
  "spacing-small": "8px"
}

Should I Use Web Components for My Design System?

Using Web Components for your Design System makes it framework-agnostic, allowing components to work seamlessly across React, Vue, Angular, or plain HTML. This ensures long-term maintainability and prevents vendor lock-in - unlike framework-specific solutions like Shadcn or Radix UI, which are tightly coupled to React.
✅ Pros: Works with any frontend framework, Future-proof, Micro Frontend compatible
❌ Cons: Tooling and SSR support can vary depending on the Web Component library
If you're building a scalable, cross-framework Design System, Web Components are a great choice.

⚡ Web Components: Stencil vs. Lit - Which One Wins?

When it comes to Web Components, two major frameworks stand out:
✅ Stencil (by Ionic)
✅ Lit (by Google)
After months of testing and talking to Design System providers, here's the truth:
Stencil is the ONLY Web Components framework that fully supports SSR with Next.js App Router.
While Lit integrates better with Storybook and Vite, it falls behind because:
❌ SSR support is limited to the outdated Next.js Page Router.
❌ Its React integration is buggy and still experimental.

✅ Why Stencil Wins:

• Full SSR support with Next.js App Router
• JSX-Support
• Optimized and workend with modern Micro Frontends

🚀 Conclusion

For Micro Frontends and Design Systems, the best combination in 2025 is:
✅ Next.js Multi Zones for SSR (Server Side Rendering)
✅ SystemJS for client-side loading (Partial Micro Frontends)
✅ Stencil for Web Components
✅ Storybook for Documentations

While Lit has better Storybook and Vite integration, Stencil is the only Web Components framework that supports SSR with Next.js App Router. After months of testing, hands-on coding, and discussions with Design System providers, I can confidently say: Stencil is the future of Web Components in modern Micro Frontend architectures.

🔥 What's your experience with Micro Frontends & Web Components? Let's discuss in the comments!

🔍 In my playground, you'll find a full Micro Frontends example with Next.js, SystemJS, Stencil, and Lit. And here plus a Storybook-Stencil integration without Micro Frontends.