Ah yes, microfrontends—because somehow, breaking your perfectly fine frontend into a convoluted mess of multiple frameworks, repositories, and depl...
For further actions, you may consider blocking this person and/or reporting abuse
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-spalibrary. 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 insingle-spais 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:
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:
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.
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.
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.
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.
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.
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.
You mentioned a component, not a framework.
If a component needs 20 files of logic that component does too much.
Add TS to your project, it reads javascript just fine.
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.
So frameworks that produce components are "foul" play? Be serious. LOL.
Irrelevant. You're interested. You have decided that that component is the one you need. Then what?
Do you think every developer is "cool" with this? There are serious TS haters out there. Like super serious.
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.
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.
Between interested and decided is a big gap, with a lot of decision making. What if the interest is only in partial functionality?
If it bothers them that much, let them compile the code and use the javascript code.
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?
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.
Imho
Micro-forntendlabel is missleading in this term. I recommend amixing-frontendinstead. 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.
With this limit's I agreed it is worth to use.
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?
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.
Fair enough, I agree, simplicity is beautiful!
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.
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.
Ok, so, how about this?
Project started 10 years ago, stuff got done in good-old Backbone.js
Devs have left (no milking), stuff still works.
Business needs new features, GenZ kids come, never heard of Backbone, they add React stuff, then leave.
Business needs more, GenALPHA babies come, they say React is old, not reactive, not functional, so they add stuff in Rimmel.js and leave.
Business needs even more, AI comes, can't fit Backbone, React and Rimmel in the same context window and it falls apart.
How is Microfrontend a scam? Business doesn't want all that works to be rewritten...
Ok, business change their mind, let's update the Backbone code first, as it's the oldest and only have budget for that...
Why would you need to rewrite legacy code if it’s working and there are no security vulnerabilities? Seriously, why? I didn’t mention this in the article, but think about it: you could have a server that serves a React app for one section of your site and an Angular app for another. Let’s take Amazon as an example. Their toys section could be built in React, and their hardware section could be in Angular. (And honestly, there are at least two other ways I can think of to do something like this.) I’ve done this without using microfrontends, and it costs very little in labor. It’s not complex at all. You can hand the React app to the Gen Z programmers and the Angular app to the old-school programmers. Sure, there might be some styling inconsistencies, but you’d get the exact same problem with microfrontends—only worse, because now you’ve added unnecessary complication.
And let’s talk about your example for a second. Do you really work in a place where you can just tell your boss, “Hey, I want to use this technology instead”? Because that’s not my experience. I’ve been freelancing for over a year, and even the least technical clients tell me, “You have to use this specific technology.” If the company uses Backbone.js, guess what? You’re using Backbone.js. You don’t get to waltz in and say, “Nah, I’ll just use React instead.” That’s not how it works in the real world. Or maybe you’ve been lucky—have you?
Here’s why I think microfrontends are a scam. Imagine you take your car in to fix a simple issue, like a broken headlight. The repair guy tells you, “Oh, you also need new seats, a new steering wheel, and new windows.” You don’t know any better, so you think, “Okay, I guess that’s how you fix headlights.” Next thing you know, you’ve got a Frankenstein car that doesn’t even work properly, and the repair guy says, “Don’t worry, I’ll keep charging you to get it working again.” But because the car is now so overcomplicated, only the best of the best mechanics can work on it. You can’t hire junior or mid-level repairmen—you need top-tier experts, which drives up their salaries even more. Sound familiar?
Microfrontends are great for senior devs, but they’re terrible for everyone else. And when the startup runs out of money (which it will), no one gets paid and the senior dev loses his job anyways but can go and sell the idea to another start up and kill it as well. If anyone suggests using microfrontends in a startup—you know, the kind of place most of us end up working—they’re either dishonest grifters or bad devs. I still can’t see why this would be useful outside of a company like Amazon. And let’s be real: your startup with 20 users and VC funding is not Amazon.
So, tell me: do you really think microfrontends are the answer? Or are we just overcomplicating things to make ourselves feel smarter and get richer?
too many assumptions... startup running out of money, car becoming a frankenstein, car not even working properly after repairs, etc.
If you like the car comparison, let's use this: you take your car for an upgrade, and you only get a new entertainment system but keep the original steering wheel, seats, wheels, motor, A/C etc. If they want to change seats and mirrors, that's the scam.
The microfrontend here is the car's frame itself, which enables you to keep all the various pieces you don't want to change.
BTW, I wouldn't want a junior mechanic who's never worked on a car like mine ever touch it. Also, if we only change the entertainment system, screen, navigation system, cameras, etc, that won't make the car anything like a Frankenstein's monster. It will still look the same, shiny, elegant blue car it was before, except with a more responsive and modern-looking entertainment system.
Perhaps some current microfrontend implementations are not optimal, not ideal, overcomplicated or plain nonsense, but it's still an implementation issue. I'm closely following a new microfrontend library being built that will make it a no-brainer using microfrontends.
You saying you don’t want a junior mechanic inherently proves my point. You’ve overcomplicated the frontend to the point where you can never hire a cheaper developer to work on it. So now, you’re stuck in a cycle where you have to keep hiring from the small pool of FAANG engineers who already command insane salaries. And guess what? To attract them, you’ll need to offer even more money than you probably have. This is great in the short term for those senior FAANG engineers—they get paid a fortune to drain a startup’s resources. But for the business? It’s a ticking time bomb.
Too many assumptions? Startups running out of money? Come on, mate. Startups—or any business, for that matter—don’t have an infinite amount of cash. Wasting money on things they don’t need is bad enough, but spending it on something that makes their software exponentially more complicated? That’s a disaster. Every time you want to make changes, it becomes more expensive and time-consuming to work on. And now you’re telling me I can’t hire junior devs—the most common and affordable developers out there. How is that sustainable?
You say microfrontends are a no-brainer when you use a library. But let’s break that down. First, you’re introducing a whole new technology that could break your entire codebase. Why? Because now you’re adding another layer of complexity and dependency. What happens when that library has a bug? Or when it’s no longer maintained? Or when it doesn’t play nicely with the other tools you’re using? Suddenly, you’re not just dealing with your app’s problems—you’re dealing with the problems of the microfrontend framework too. And guess who gets to fix all that? Not the junior devs, that’s for sure.
You compared microfrontends to a car’s frame, saying it lets you keep all the pieces you don’t want to change. But here’s the thing: a car’s frame is simple, reliable, and doesn’t require constant maintenance. Microfrontends, on the other hand, are anything but. They’re more like adding a second frame on top of the first one, with a bunch of extra bolts and screws that nobody knows how to tighten. Sure, you can upgrade the entertainment system, but now you’ve got a car that’s harder to drive, harder to fix, and harder to understand.
And let’s talk about your shiny, elegant blue car. You say it’ll look the same, just with a more responsive entertainment system. But what about the cost of that upgrade? What about the time it takes to install it? What about the risk of breaking something else in the process? And what happens when the next big thing comes along, and you need to upgrade again? With microfrontends, every change becomes a project in itself. It’s not just about the entertainment system—it’s about the entire ecosystem you’ve built around it.
You’re following a new microfrontend library that promises to make this all a no-brainer. But let’s be real: every new framework or library comes with the same promises. “It’ll solve all your problems! It’ll make everything easier!” And then, a year later, you’re stuck with a bloated, overengineered mess that nobody knows how to maintain. Maybe this new library will be different—but do you really want to bet your business on it?
Microfrontends might sound great in theory, but in practice, they’re a recipe for disaster. They overcomplicate your frontend, lock you into expensive hiring practices, and make every change more costly and time-consuming. And for what? A slightly shinier entertainment system? It’s just not worth it.
backbone.js forever 😃
I remember applying for Backbone.js job spending the whole weekend preparing and researching; only for the the Hiring Manager to say he wasn't bothered to update the job post and it was actually for React but with some backbone migrating. I love this career :D
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.
Eh, this is about micro-frontends, not micro-services.
Ok got me, I have a new thing to study.
Ironically enough, I do like Micro Services and I think they are very useful!
Thank you so much for the feedback! I absolutely agree with all your points:
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.
Well, yeah of course if you come to the conclusion that you need MFE without actually understanding why other companies who've successfully used MFE in the past have actually used them, you're going to have a bad time.
Yeah, agreed. Unless you’re dealing with a massive frontend like Amazon or a platform with multiple autonomous teams working on different sections, MFEs are usually overkill. Most apps can be managed just fine with a well-structured monolith or modular architecture without the extra complexity.
what a flame in the comments.. seems that somebody's "aces" are burned out 😃😃😃 use jquery 😃😃😃
Why not :D
dunno. may be 'cause there is nothing to argue with... the post is deliberately true 🤷♂️
Thanks Lool, I used to like Jquery but then they made JS easier to use! Thanks for the comments!
Hello my freand
Hey Buddy!
i loved this post, i thought i was alone thinking how complex and unnecessary them are, they dont solve the true problem, distract from the center of solution and make harder than must be.
Exactly! A lot of people get caught up in hype-driven development without questioning if the complexity is actually worth it. MFEs often introduce more problems than they solve, especially if the real issue is poor architecture or lack of team coordination. Keeping things simple and focusing on maintainability usually leads to a better outcome.
Why do you rant about something that you don't understand?
MFA is a completely valid pattern, imagine a platform for several applications that are developped into this framework by hundreds of people, with a shell around it.
Especially when the apps that are added to this framework are working as standalone apps too, so you won't migrate the app to a completely different framework.