Shaunak Das

Posted on Feb 26

Micro-Frontends: The Next Big Thing or Just Hype?

#frontend #webdev #react #javascript

If you’ve been anywhere near web development circles lately, you’ve probably heard the buzz about micro-frontends.

It’s being pitched as the shiny new solution to all our frontend woes—modular, scalable, team-friendly. But is it really the game-changer it’s hyped up to be, or just another buzzword destined to fade into obscurity? Let’s break it down.

What Are Micro-Frontends, Anyway?

Think of micro-frontends as the frontend cousin of microservices. Instead of one giant, monolithic app, you split your UI into smaller, independent pieces.

Each piece can be owned by a different team, built with its own tech stack, and deployed on its own schedule. Imagine a dashboard where the navigation bar, a widget grid, and a settings panel are all separate apps, stitched together seamlessly (or so the theory goes).

The promise? Faster development cycles, easier scaling, and happier teams who aren’t stepping on each other’s toes. Sounds dreamy, right?

But like any shiny new toy, it comes with trade-offs.

The Good: Why They’re Turning Heads

First off, micro-frontends shine when you’ve got big teams or sprawling apps. If you’ve ever waited for a 20-person team to align on a single release, you know the pain. Splitting the frontend lets teams move at their own pace—Team A can ship a new feature while Team B polishes their widget, no bottlenecks required.

They’re also a godsend for legacy migrations. Got an old monolith you’re dying to modernize? Micro-frontends let you incrementally replace chunks of it without a full rewrite.

Start with a new sidebar in React, keep the rest in jQuery, and phase things out as you go. Check out this intro to micro-frontends by Martin Fowler for a deeper dive into the concept.

And let’s not forget flexibility. Want to experiment with a new framework? Go for it—one micro-frontend can be Vue, another Svelte, and the rest whatever your team’s comfy with. No more "all-in" framework bets.

The Messy: Where It Gets Complicated

But here’s the catch: simplicity isn’t free. Stitching those independent pieces together can feel like herding cats. You’ve got to figure out how they talk to each other—shared state, routing, and styling become your new headaches. Ever tried keeping a consistent look when three teams are wielding their own CSS? Good luck.

Performance is another gotcha. Each micro-frontend might load its own dependencies, so you could end up with duplicate libraries clogging the browser. Sure, there are tricks like Webpack’s Module Federation or server-side composition, but they add complexity. And complexity, as we all know, is the enemy of deadlines.

Bundle Size Comparison

Approach	Bundle Size (MB)	Key Notes
Monolith	5.0 MB	Single, unified bundle. No duplication, but includes everything upfront.
Micro-Frontends (Duplicates)	8.5 MB	Each micro-frontend loads its own dependencies (e.g., 3x React at ~2 MB).
Optimized Micro-Frontends	6.2 MB	Shared dependencies (e.g., via Module Federation) reduce redundancy.

Explanation of Values

Monolith (5.0 MB): A single app with all features bundled together. Efficient in terms of no duplication, but it can grow unwieldy for large apps.
Micro-Frontends with Duplicates (8.5 MB): Assumes three micro-frontends, each bundling a framework like React (~2 MB) plus their own code. Duplication bloats the total size.
Optimized Micro-Frontends (6.2 MB): Uses shared dependencies (e.g., one React instance via Module Federation), cutting redundancy while still splitting the app.

Then there’s the tooling. Micro-frontends aren’t as plug-and-play as a monolith yet. You’ll likely need custom build pipelines, deployment scripts, and a solid CI/CD setup. Tools like Nx can help here—its monorepo approach is a lifesaver for managing multiple micro-frontends in one cohesive workspace. Their micro-frontend guide is worth a peek if you’re curious.

Real-World Vibes: Is It Worth It?

I’ve been knee-deep in micro-frontends lately, and here’s my take: they’re not a silver bullet, but they’re not hype either. They’re a tool—one that’s clutch when your app’s big, your team’s distributed, or your roadmap’s a moving target. For a small startup churning out an MVP? Probably not worth the hassle.

The key is knowing your context. If your app’s complexity is outpacing your ability to ship, micro-frontends might save your sanity.

But if you’re just jumping on the bandwagon because it’s trendy, you might end up with a fragmented mess and a lot of regret.

So, Next Big Thing or Just Noise?

Micro-frontends aren’t here to replace everything—they’re an evolution, not a revolution. They solve real problems for the right projects, but they’re not a one-size-fits-all fix. The hype’s loud, sure, but beneath it lies a practical approach that’s earning its keep in the wild.

Should You Use Micro-Frontends?

Question	Yes	No	Outcome After All Questions
Do you have a big team?	Move to next question	Move to next question	-
Is your app complex?	Move to next question	Move to next question	-
Need independent deploys?	If Yes to any prior question: "Go for it"	If No to all: "Stick to the monolith"	Final Decision

What do you think—are micro-frontends the future, or just another chapter in the endless frontend saga? Drop your thoughts below; I’d love to hear how they’re working (or not) for you!

Happy coding!🚀

Top comments (16)

Peter Vivo • Feb 26

I vote on micro frontend without fw. My POC solution is keep each html page distinct and don't use framework, just a JSX and Tailwind which is give at the end a really minimal cose size. I know this method don't fit for a larger application, but I try to push forward this idea: dev.to/pengeszikra/javascript-grea...

Shaunak Das • Feb 27

Hey Peter, thanks for sharing your POC! Going framework-less with JSX and Tailwind is an interesting angle—definitely keeps the bundle lean, especially for smaller projects. I can see the appeal for minimal setups, and it’s cool you’re pushing that boundary. You’re right though, scaling that up could get tricky with larger apps needing more structure. Have you run into any specific challenges with state management or routing yet? Would love to hear more!

Peter Vivo • Feb 27

I using zero routing: each independent html can call as route. I did not reach the next state where need to be pass some minor state to a page, or even I try to process the url parameters.

State handling is this simple function don't need to bind to view even work on nodejs side also:

/** @type {<T>(watcher?: function) => (state?: T | object) => T} */
export const signal = (watcher = () => { }) => (state = {}) => {
  return new Proxy(state, {
    get: (target, prop) => target[prop],
    set: (target, prop, value) => {
      target[prop] = (value !== null && typeof value === 'object')
        ? signal(watcher)(value)
        : value
        ;
      watcher(target, prop, value);
      return true;
    },
  });
};

Craig Morrison • Feb 27

I think the issue with scaling this approach up to a large scale where micro-frontends have a use case isn’t technical but social.

You’re essentially creating your own lightweight framework, which can be very efficient and personally rewarding. However, on a big project that’s extra onboarding friction for developers and a lot to document and explain to a large team.

Peter Vivo • Feb 27

You right. This solution is not battle tested. For a big project need a solution which have easy onboarding friction. It just reflect as POC stuff, if we found a real lightweight FE solution then don't need to build a monolith application. Because as I know the monolit solution is download too much extra dependency ( even a too complex CSS sytem ) to every page, or using a SPA which is same.

GP • Feb 27

We have implemented micro-frontends using webpack mod fed, and it's working fine for us. We are also exploring Bit.dev and OpenComponents to see how they can fit into our existing front-end ecosystem and bridge the gap of micro frontends known challenges.

José Pablo Ramírez Vargas • Feb 27

Module Federation is not a real MFE solution. It is just a way to share modules. You can only do MFE if they are the same technology: React to React, Vue to Vue, etc.

The best real MFE solution is single-spa. It is technology-agnostic and is incredibly simple to use.

GP • Feb 27

I appreciate your astute observation, Our development philosophy indeed emphasizes a streamlined, one-to-one approach rather than amalgamating numerous frameworks and libraries within a single application. This strategy is rooted in several key principles:
Performance Optimization, Maintainability, Scalability, Developer Efficiency, Reduced Learning Curve, Stability, Clear Architecture and Future-Proofing.

This philosophy of simplicity and focus aligns with best practices in software engineering, emphasizing the creation of robust, efficient, and sustainable applications. It allows us to deliver high-quality solutions while avoiding the pitfalls associated with overly complex technological ecosystems (single-spa, next, remix etc.,).

José Pablo Ramírez Vargas • Feb 27

An AI response if I have ever seen one.

I don't know why you feel the need to explain yourself. Do as you must. I just pointed out a limitation of Module Federation and volunteered an alternative.

Shaunak Das • Feb 27

Great to hear micro-frontends are working well for your team with Webpack module federation, I’m curious about your experience with Bit.dev and OpenComponents—are there any particular challenges or benefits you’ve noticed when integrating them into your front-end ecosystem? It’d be helpful to learn how they’re addressing the gaps you mentioned.

José Pablo Ramírez Vargas • Feb 27

The decision matrix is incorrect, or at the very least, incomplete, because it doesn't take into account the migration of frameworks. I just thought I should mention it if anyone will really use it to decide.

Shaunak Das • Feb 27

Hey José, good catch—thanks for pointing that out! You’re absolutely right that framework migration can be a big factor, especially with the overhead it might bring. I focused on the high-level decision points, but adding migration complexity (e.g., gradual adoption or tech debt) would definitely make the matrix more robust. I’ll consider updating it—any thoughts on how you’d weigh that in the decision process? Appreciate the input!

José Pablo Ramírez Vargas • Feb 27

I'd say it is very important. Even for a team of 1 developer, micro-frontends should be a great option to gradually move from one old, cracked and hopeless (React, hehe) technology into a newer, faster, better, funner (Svelte! 😄) technology.

Dmitrii Boikov • Feb 27

HI. Thanks for the article. I thought that currently, everyone is in full power for Next.js and such as the next shiny thing.

I'm currently working on an article about NX mono repo, and firstly, I wanted to comment that micro frontends are not that useful for most products. Still, I realized that the Micro-Frontend is the next logical step in the mono-repo setup.
It changed the direction of my article a little bit🙂