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:
You shouldn't have different teams, or
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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-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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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.