🚨 Micro-frontends: The Dumbest Idea Tech Bros Have Ever Sold to Businesses 🚨

Ah yes, microfrontends—because somehow, breaking your perfectly fine frontend into a convoluted mess of multiple frameworks, repositories, and deployment pipelines is the future™.

"We need independent teams!" they scream.

"We need better scalability!" they insist.

"We need microfrontends!" they whine, without a single clue why.

Let me tell you the real reason microfrontends exist: To make software engineers look smart while bleeding businesses dry.

🤡 How to Overcomplicate the Simple

For years, we’ve had modular architectures. We’ve had reusable components, lazy loading, and optimized build pipelines—all of which solve the same problems without turning your app into a dumpster fire.

But no, that wasn’t enough. Instead, some genius decided:

"Hey, what if we take our frontend and smash it into a thousand tiny pieces, each requiring its own framework, build process, and deployment strategy? Sounds smart, right?"

And thus, the clown show known as microfrontends was born.

🎭 The Reality of Microfrontends

Let’s talk about what really happens when you go down this rabbit hole:

1️⃣ Your app becomes an incoherent mess 🧩 – One page is React, another is Angular, and suddenly Vue.js is lurking in the corner like an unwanted guest.

2️⃣ Performance nosedives into the ground 💀 – Because, of course, loading three different JavaScript runtimes on the same page totally makes sense.

3️⃣ Styling consistency? HA! 🎨 – Every team rolls their own styles, breaking your design system beyond repair.

4️⃣ Debugging turns into a full-time job 🔍 – "Why is this page broken? Oh, right, because it was built by a separate team in a completely different repo with zero coordination!"

5️⃣ Deployments become a nightmare 😱 – Hope you enjoy spending weeks figuring out which microfrontend update broke the entire app.

But hey, who cares about any of this? It’s modern engineering, right?

🏆 The Scam: How Engineers Sell Microfrontends to Clueless Executives

The best part? Business people fall for this nonsense every time.

Why? Because they don’t understand tech, and engineers love taking advantage of that.

All it takes is a few buzzwords in a PowerPoint:

✅ "Independent deployments!"

✅ "Scalability!"

✅ "Autonomous teams!"

✅ "Microservices, but for the frontend!"

And boom—millions of dollars get flushed down the drain on unnecessary complexity.

Meanwhile, the engineers pushing this garbage cash in on consultant fees, job security, and endless infrastructure budgets.

Because guess what? The harder your system is to understand, the more valuable they become.

🔥 Disagree? Get Fired

And here’s the kicker: If you dare to question this stupidity, you get labeled as ‘resistant to change.’

💀 "Oh, you just don’t want to adapt!"

💀 "You’re a junior dev who doesn’t understand modern architecture!"

💀 "This is how FAANG does it, so it must be good!"

The moment you challenge the microfrontend scam, you become a threat. And since tech is a glorified popularity contest, they’ll shove you out the door before admitting they’re wrong.

💸 Who Actually Benefits?

Let’s be honest—microfrontends only exist to:

💰 Sell more cloud infrastructure – AWS, Google Cloud, and Vercel love when companies waste money on microfrontend garbage.

💰 Give engineers job security – The more complex your system, the harder it is to fire them.

💰 Let consultants milk businesses for all they’re worth – Because someone has to "train" your team to deal with the chaos they created.

Meanwhile, the actual product? Slower. Buggier. More expensive.

🚀 The Simple Alternative (That Actually Works)

If you actually care about your business (and your sanity), do this instead:

✅ Use a well-architected monolith – Modern frontend frameworks already support modularization without the insanity.

✅ Leverage component-based design – Break things up inside a single codebase, instead of spawning 10+ unnecessary repos.

✅ Use lazy loading and code splitting – You don’t need a different framework for each page. Just load what you need, when you need it.

But no—why do things the easy way when you can create a bloated, overengineered disaster that guarantees job security for bad engineers?

🔥 Final Thoughts: Stop Falling for the Bullsh*t

If you take one thing away from this, let it be this:

Microfrontends are a scam.

They don’t improve performance.

They don’t make development easier.

They don’t solve any real problems that can’t already be solved with better architecture.

The only thing they do? Make incompetent engineers look smart while setting businesses on fire.

So next time some clown tries to sell you on microfrontends, tell them to get lost. 🚀

Comments

[José Pablo Ramírez Vargas]

Hmmm, someone didn't follow a good decision matrix, I'd say.

To put this in a more balanced and informed perspective for readers: As a whole, this is just a rant coming from a person that may not have followed a good decision matrix before embarking into MFE's.

More Elaborate Explanation

If you apply micro-frontends blindly, most of what this article claims might become true. You really need to think about why you're after micro-frontends so you don't fall into this guy's nightmare.

My experience with micro-frontends has been with the excellent single-spa library. To me, there is nothing better. Unlike Module Federation, this is a true MFE solution. Its simplicity will do the rest: It defines a standardized, framework-agnostic interface API (a contract, an interface) that shields away the specifics of the framework/library in use and that's it! The rest of the stuff in single-spa is mostly related to routing and a very convenient trick.

Select your MFE Technology Carefully

So I can tell you, from the get-go, that your selection of MFE helper will greatly influence your opinion on this subject. To put you, reader, in perspective, look for Piral. That has to be the most over-engineered solution in existence today! From a specialized CLI to a cloud service, you need all of these or nothing works.

Make Sure You Need MFE's

As stated: You must have a valid reason to want this. "To learn" is not a valid option for your work project, hehe. Learn on a pilot project.

Valid reasons are varied, but most commonly:

• Open application. Your application is "open to collaboration" and you want to be as inclusive of frameworks as possible. MFE's are ideal here.
• Migrating technologies. Your application is in ugly React and you want to gradually move it to awesome Svelte or SolidJS. MFE's allow you and your team to pace this effort as fast or slow as you wish.
• Complex application. Or is it!?? Maybe it isn't. This is frequently found as a good reason, but I don't share the same vision. I would give this "reason" a very low weight. Why? For some of the reasons listed in this rant: Why would you add complexity to an already-complex project? Not as simple as this, though. Every case is unique.
• Necessity. What if your marvelous VueJS application needs a component only available in Svelte? An MFE might work wonders here.

What about the buzz words in the article, like "scalability" and "team independence"?

Scalability can be measured. If you need more web servers, then MFE's naturally allow scaling web servers for the parts that are most used. But let's be honest: If your entire application weighs less than 10MB, scaling up the part that is used most only really matter? How different would it be if you were to add more web servers for the full 10MB?

Team independence is a real thing. By having different teams per MFE, then each team can set their own linting rules, naming conventions, etc. If you're going to rant (as above) about how "everything is different now", then maybe:

1. You shouldn't have different teams, or
2. You should establish the same rules for all teams.

So, in other words: If you allowed different teams to start with, you should have known this was going to happen. Ranting about it is just hypocritical.

---

So there you go, some perspective for this apparently hot topic.

[david duymelinck]

I think there are use cases for micro front-ends. But I think it is a niche tool, instead of the new way of building front-ends in the browser.

What if your marvelous VueJS application needs a component only available in Svelte? An MFE might work wonders here.

That is not a valid reason to switch to a micro front-ends structure. If you need a component that is already build, steal the logic and build it in the framework the application uses.

If you need more web servers, then MFE's naturally allow scaling web servers for the parts that are most used.

How do micro front-ends allow scaling? Dynamic loading is the same for micro front-ends as for a code splitted monolith. The scaling is done by the server infrastructure.

Maybe it is an unfortunate name, but the SPA portion of single-spa leaves a bad taste in my mouth. I thought the javascript community was over the SPA hype. There are use cases for SPA but again they are a niche.

[José Pablo Ramírez Vargas]

That is not a valid reason to switch to a micro front-ends structure. If you need a component that is already build, steal the logic and build it in the framework the application uses.

Svelte v5 uses custom and efficiency-optimized signals. This is not something you could easily port. Generally speaking, it tends to be simpler to use an MFE rather than porting. Also, what if the logic is spread across 20 files? What if it is TS and your code is JS? What if the code base is 7.000 lines? Etc. Point being: It is naive to think you'll always be able to port like nothing. Another important one: If you port, you assume the responsibility of maintaining the ported codebase. Isn't it better to rely on a 3rd party to maintain the code for you? Worst case scenario, it is not maintained. Then you port.

How do micro front-ends allow scaling? Dynamic loading is the same for micro front-ends as for a code splitted monolith. The scaling is done by the server infrastructure.

We (our team) deploys each MFE as an independent Nginx server in K8s. If anything needs scaling, the particular pod count is increased. That's how.

[david duymelinck]

Svelte v5 uses custom and efficiency-optimized signals. This is not something you could easily port.

You mentioned a component, not a framework.

what if the logic is spread across 20 files?

If a component needs 20 files of logic that component does too much.

What if it is TS and your code is JS?

Add TS to your project, it reads javascript just fine.

MFE as an independent Nginx server in K8s

That is are micro services. It just proves the point I was trying to make. If you want to scale micro frond-ends you need micro services.
Scaling is not a micro front-ends benefit.

[José Pablo Ramírez Vargas]

You mentioned a component, not a framework.

So frameworks that produce components are "foul" play? Be serious. LOL.

If a component needs 20 files of logic that component does too much.

Irrelevant. You're interested. You have decided that that component is the one you need. Then what?

Add TS to your project, it reads javascript just fine.

Do you think every developer is "cool" with this? There are serious TS haters out there. Like super serious.

Scaling is not a micro front-ends benefit.

That's also my point. Read carefully.

So your arguments really aren't solid at all. I'll put a nail in the coffin with one more scenario: You want to port a component, but nobody in the team knows the framework. The expertise is just not there. It is a complex application and AI cannot produce a port that works. Now what? I'll tell you what: I found a scenario where your only solution is, by definition, out of the equation.

My point being: My original point: Micro-frontends do provide a helpful solution if you want to use a component that is not natively compatible with your project. MFE's are viable in all of the scenarios I have proposed while your porting solution fails at many of these.

[david duymelinck]

So frameworks that produce components are "foul" play? Be serious. LOL.

I understand your reaction, I didn't formulate it right. If a component uses framework related behaviour you port that to the behaviour that is available in the framework.

Irrelevant. You're interested. You have decided that that component is the one you need. Then what?

Between interested and decided is a big gap, with a lot of decision making. What if the interest is only in partial functionality?

Do you think every developer is "cool" with this? There are serious TS haters out there

If it bothers them that much, let them compile the code and use the javascript code.

You want to port a component, but nobody in the team knows the framework. The expertise is just not there.

You don't need to understand the code to see what the component does. Porting is never a one on one process.
If nobody in the team knows the framework, why would you start using the framework for one component?

MFE's are viable in all of the scenarios I have proposed while your porting solution fails at many of these.

I never mentioned all scenarios. I singled out the necessity scenario, because i find the example a weak reason to start using micro front-ends.

[José Pablo Ramírez Vargas]

Between interested and decided is a big gap, with a lot of decision making. What if the interest is only in partial functionality?

Again, irrelevant. Let's say the component does ëxactly what yoiu need.

If nobody in the team knows the framework, why would you start using the framework for one component?

OMG!! Because you need it!! Are you playing the irrational game or something? Because you don't know the framework the component doesn't work?? Are you a rational-thinking person? Do you know every language? If I made a tool in a language you don't know, would you refuse it? It works, but you don't understand the language. It fulfills your need, but you cannot maintain it. Are you rejecting it? That's irrational.

I never mentioned all scenarios. I singled out the necessity scenario, because i find the example a weak reason to start using micro front-ends.

And I have demonstrated extensively that it is one of the best reasons to use MFE's, whether you want to play dumb or not. Play dumb all you want. You're wrong and I have fully demonstrated it.

[david duymelinck]

I'm going to rewind.

What if your marvelous VueJS application needs a component only available in Svelte?

You are mentioning a component. I assume this is one component.

I think these are the steps that are needed to go to a micro front-ends application:

• Moving the Vue js application to a subdirectory
• adding single-spa and setting it up
• change the build script
• run tests to see if all urls still function
• adding a new directory for the Svelte app and setting up the Svelte framework and the component
• add the Svelte app to the build script
• Write tests for the component
• Because it is a component it probably is going to be mounted somewhere in a layout that is written in Vue. So the layout has to be rewritten?
• Write tests to verify the component appears.

Lets compare this with the steps if the component gets ported

• research how the component behaves
• create the component in Vue.
• write tests
• Add the component to the Vue application
• Write tests to verify the component appears.

There are a lot more things that can go wrong if you transform an application to use micro front-ends than creating a component from scratch.

Why have the frameworks all have similar components, because they are ported from one framework to another. You act like it is not a common thing.
And what is wrong with taking responsibility for a component that is needed?

[José Pablo Ramírez Vargas]

This is exactly why one must research before posing as a knowledgeable person. I have encountered several here, and I suppose I'll continue to encounter. Why is people compelled to speak as if they know things? I'll never know.

In single-spa there's the concept of the root application and the MFE's. Furthermore, MFE's can be generalized in parcels. All these are concepts of the library. Knowing them is fundamental. Because you don't know any of these, you keep failing. Let's start.

Moving the Vue JS application to a subdirectory

Not needed if you do multiple repositories. Regardless: Takes 5 seconds.

Adding single-spa and setting it up.

npm i single-spa

Setting up? No needed for parcels, which is the ideal route to reuse components. So, 5 more seconds.

Change the build script

The VueJS application needs to convert to a single-spa root. I, the creator of the only Vite plug-in in existence for single-spa, can tell you that it takes one package (my plug-in), then 3 or 4 lines of code in vite.config.js. Virtually done in one minute.

Adding a new directory for the Svelte app and setting up the Svelte framework and the component

Setting up is running npm create vite@latest. Basically, create a new project. Time: 1 minute.

Write tests for the component

Why? You didn't author it. For example, if you want to use my @wjfe/dataview table component for Svelte v5, it is backed up by over 120 unit tests that I made for it. Why would you take on this task?

Do you know why sometimes the test files have a .spec file extension? It stands for "specification". This means that whoever conceptualizes the piece of software is the one qualified to define what it is considered to be "under specification".

Time 0s

Because it is a component it probably is going to be mounted somewhere in a layout that is written in Vue. So the layout has to be rewritten?

If you're re-writing to exclude an inferior component, no. You just replace the component with the single-spa parcel.

If you're adding new functionality, you needed to add markup to hold the component anyway, be it an external parcel, or a native component.

This adds 0s to this route and is actually present in both routes (MFE and porting).

Write tests to verify the component appears.

Same as above: Porting or MFE, this is required. 0s

Why have the frameworks all have similar components, because they are ported from one framework to another. You act like it is not a common thing.

Ok. NP. Take my table component done in Svelte. It has a one-of-a-kind feature: It can visually synchronize columns of parent and child tables. If your project requires a data table that can do this, there is not a single other component in the world right now that can do it.

The algoritm that powers this feature is fully dependant on Svelte signals. Care to port it to React, where there are no signals? Please do and tell me how much time it took. In the meantime, let me summarize how much time we have to invest setting up single-spa.

Setting up your project to consume single-spa probably takes about 3 hours. It would take me, that I have done it fully several times, 30 minutes.

And what is wrong with taking responsibility for a component that is needed?

The day you become the tech team leader of your team, where you are responsible of maintaining backlog and when you have to ensure tech debt is covered, you'll arrive to the answer: It is not wrong, it is extra work. But you'll understand if you ever become a tech team leader.

[david duymelinck]

Thank you for the information.

While it looks very simple from your explanation. It adds more cogs to the machine. Instead of one application, there are three now? The single-app is also an application if i read the documentation right.
That means the deployment and the monitoring changes.

[José Pablo Ramírez Vargas]

2 applications with my approach. While I do sustain that single-spa is the best of all, it has this annoying recommendation to create a UI-less root project, and has 3 design flaws.

If you're interested in taking full advantage of single-spa, read my blog series. This series explains my learning process and how I created the plug-in vite-plugin-single-spa.

Summary

The UI-less root config is wasted effort. I discard this recommendation and therefore 2 MFE's, not 3. I am in the process of experimenting with only parcels and dumping the MFE concept in single-spa.

I created this Svelte v5 router with the necessary features to maximize micro-frontend usage. This will allow me to completely dump single-spa's routing capability, reducing everything to just parcels.

This will ultimately give birth to a new MFE library that corrects the 3 design flaws and works with just the concept of parcels. If you are interested in seeing how I do with all these, follow me.

[Itamar Tati]

Thanks for your feedback on the article! I can see why micro-frontends would be great if you work at a company like Amazon, where you have a lot of teams and need that level of division. I’ve never worked at a company with a codebase that large, so I can’t fully relate. However, I don’t understand why this can’t be handled on the server. Why does the separation have to happen on the frontend? Why can’t you simply have a React app for the toys section and an Angular app for the hardware section when making requests to the server?

Also, regarding your point about migrating from React to Svelte—does that really happen? Do business leaders who have spent money on a codebase really decide to refactor everything, paying an entire team to rewrite the codebase without adding any new features, just to make developers’ lives easier? If that does happen, keep that job a secret, because every engineer I know would want to work for someone willing to pay them for that!

[José Pablo Ramírez Vargas]

It happened, and I drove the change. Well, I'm driving the change. We have only started. But it was never a deal "without any new features". There were pending features and bug fixes. We reached to the conclusion that the React codebase was too messy. We are only 5 devs and we wanted something effective. I investigated front-end solutions and came to know Svelte. Testing it I concluded that Svelte could do what React does in about 35% less code. I requested approval for Svelte from the architects and we started.

Also, Intel keeps record of the "happiness" score of all teams. It is measured after every 2-week sprint. React was making our devs unhappy. Therefore, one more reason to push Svelte.

[david duymelinck]

For the company, it is in his profile.

[Itamar Tati]

Lol I saw (Intel), unfortunately I work with small businesses and start ups that don't have the money to do Micro Frontends. I was at a start up were my head of engineering suggested this and all I could think was why? But he was from a big tech company as well. All I can say is that it doesn't make sense when you have a small code base, not a lot of money and you're not solving user problems.

[david duymelinck]

if the code already is a modular monolith. The step to micro front-ends will be smaller. If the code isn't modular it is harder to go to a micro front-ends structure.

Scaling is a tailor made process for each project. But concepts like micro front-ends can help to find the right solution for the scaling problem the project is experiencing.

Or find a solution to move away from UI frameworks. Concepts are never a silver bullet, but a way to help you to come to a solution that can be understood by other developers.

[Itamar Tati]

Thanks for the explanation, much appreciated.

[José Pablo Ramírez Vargas]

if the code already is a modular monolith. The step to micro front-ends will be smaller. If the code isn't modular it is harder to go to a micro front-ends structure.

Just so everyone one is clear: Regardless of size or complexity, since every React/Vue/SolidJS/Svelte project I've ever seen starts with one root component, converting a project to an MFE takes about 15 lines of code with single-spa. So the above quote is not true. The conversion is all about exporting the root component. It is one component regardless of size. The size or internal structure of the project doesn't matter.

This is why you must talk to people who have had the experience. Don't be fooled by people who haven't done things.

[david duymelinck]

I agree I have not done it.

If you keep one entry point how are you going to split it in multiple applications?
You need an entry point per application, right?

[José Pablo Ramírez Vargas]

Yes. But when you start, you only need to convert one root.

Only after starting you can say things like "modularization helps to more easily disect this into MFE's".

Still, what if it isn't modular? That's not excuse not to make it modular, and MFE is modular by defintion.

[david duymelinck]

The main lesson I learned from creating micro services is that it is better to create a modular monolith first and run that for a time to monitor if the modules need to be fine-tuned. And after that stage is completed, move the modules to micro services.

That is the base of my modular monolith remark.

[José Pablo Ramírez Vargas]

It is a good approach and certainly mirrors what one should do in the front-end space as well.

Starting with a modular project is always better for partitioning, regardless of being back-end or front-end.

[Peter Vivo]

Imho Micro-forntend label is missleading in this term. I recommend a mixing-frontend instead. I totally agreed with you in this term the whole stuff easly go to chaos if don't controlled at architect level.
In my reald-world experience a legacy based React application is a good indicator point to changing will be recommend. A further excalation point is a high developer/management changing rate ( world scale project ) so the newcomers don't have too much time to get experience a project, and of course the documentation even architect level is non exist. But somehow works. But back to a code, if micro is means frontend is really micro I welcome it.

But let's do a line:

• micro-frontend don't use more than 5 different dependency.
• a single HTML JS/CSS part don't be greater than 100k.
• a building time need to be under 10s

With this limit's I agreed it is worth to use.

With my hobby game project, I was keep those limitations flogon-galaxy, but with inexperienced developers or high fluctuation this limit is hard to realize.

[Itamar Tati]

Okay these limitations look great if the tech bros get to my boss and I'm forced to use Micro-Frontends I will have a way not to mess it up too much! @pengeszikra from you experience working on flogon-galaxy was it generally better to work with Micro-frontends?

[Peter Vivo]

Honestly, I don't focusing to ride a hype. According my real-world job I just would like to try how can I simplify the development. The minimal dependecy is my first key point. Originally I started the work without build system, even I just put Tailwind as a CDN script link ( work very well on POC level - without any build ), at that point when I turn to think application as a independent HTML pages instead of SPA. That is a turning point and a great help.

[Itamar Tati]

Fair enough, I agree, simplicity is beautiful!

[david duymelinck]

I agree it is an confusing name, but the concept is very close to micro-services.
Both of them force you to think in a modular way. And they also allow to choose the base for the modules.

Mixing-frontend is too much emphasis on the base part choice. While it is a part of the concept it should not be used to load more code.

Micro-services shine in the backend because there are languages that have different strengths. But in the front-end it is only javascript.

I think the best use case is to move from UI libraries/frameworks to plain javascript. But that is because I don't want to burden users with UI code that can be replaced by HTML, CSS and javascript functionality that comes out of the box.

[José Pablo Ramírez Vargas]

How would those limits work? For example, our work project, when written completely in React, averaged 1.5MB across 6 MFE's. If I were to follow your tiny requirements of a 100K maximum, even migrating to marvelous Svelte I would end up with dozens of MFE's.

My point here: It is not as simple as saying figures.

[JWP]

I think the majority of what was mentioned deals with architecture not microservices.

Moving to a microservice requires one simple change in the front end, just call the microservice not the backend. Pretty simple. Additionally, the call is to an http endpoint which is simple.

Just a thought.

[José Pablo Ramírez Vargas]

Eh, this is about micro-frontends, not micro-services.

[JWP]

Ok got me, I have a new thing to study.

[Itamar Tati]

Ironically enough, I do like Micro Services and I think they are very useful!

[Stuart Haas]

I have zero experience with micro front-ends, but I understand the concept. Overall, I've observed that there is overcomplexity in the implementation of the presentation layer. Also, it's obvious this is a major point of frustration for you. I will also point out that you will be met with elaborate responses in defense of what actual are poor design decisions as a whole. People who desire to defend the truth will be met with persecution. Typically, over explanation is a sign of a deep rooted issue. If it wasn't problem, then there wouldn't be people such as yourself taking the time to write this. Lack of unity in the engineering community is our greatest downfall, but this doesn't mean we haven't achieved great things. It is absolutely exhausting to defend our belief systems but don't give up! There is beauty in simplicity.

[Itamar Tati]

Thank you so much for the feedback! I absolutely agree with all your points:

People who desire to defend the truth will be met with persecution. Typically, over-explanation is a sign of a deep-rooted issue. If it wasn’t a problem, then there wouldn’t be people like yourself taking the time to write about it.

I completely agree that keeping things simple is crucial for software engineers. The more we complicate technology, the harder it becomes to solve problems efficiently. This leads to companies spending more money than necessary, losing trust in tech, and ultimately canceling projects.

There’s also an unintended effect—if we had more successful tech projects, more people would be willing to invest in technology. Additionally, all these layers of complexity make it harder for companies to hire junior developers, even though most of us got our first jobs as junior devs.

[Syafriadi]

Hello my freand

[Itamar Tati]

Hey Buddy!