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.
Again, irrelevant. Let's say the component does Ă«xactly what yoiu need.
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.
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.
I'm going to rewind.
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:
Lets compare this with the steps if the component gets ported
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?
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-spathere'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-spaand setting it up.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-sparoot. I, the creator of the only Vite plug-in in existence forsingle-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/dataviewtable 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
.specfile 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-spaparcel.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
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-spaprobably takes about 3 hours. It would take me, that I have done it fully several times, 30 minutes.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.
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.
2 applications with my approach. While I do sustain that
single-spais 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.
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!
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.
For the company, it is in his profile.
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.
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.
Thanks for the explanation, much appreciated.
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.
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?
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.
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.
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.
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!
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.
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 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!
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.
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.
Hello my freand
Hey Buddy!