Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
I'm 17 minutes in and getting really distracted by the fact that the point is getting missed.
I've been building a microfrontend for almost a year, and there are good points made around app-size/company size, etc.
But the REAL benefits are avoiding framework lock-in and stability. If I build a microfrontend component (spec compliant web component) and package it up into an npm package, that component lives forever.
I don't have to go back and modify it every time a new version of the framework comes out.
In addition, think of it from the perspective of going framework-less, not in terms of the frameworks (as the microfrontend site example is pretty tortured). The whole POINT of these frameworks, going back a decade, was to allow us to separate concerns and componentize (work in the average jQuery app circa 2008 and you'll know what I mean haha). This isn't about using all the frameworks, this is about not needing them anymore.
If everything is a purely contained component that can run on its own completely independently, then you have a design system, not an application.
If you then compose a set of components into a larger "frame" component, and that frame has an API that it calls on the backend to where each microfrontend is a vertical slice of the application, then it becomes ridiculously trivial to make changes.
You CAN do that with a good component model. Now, change the framework version in an app without a microfrontend.
Example from the real world: Spend five years writing an Angular 1.X site with a bunch of element directives. Now you've finally convinced leadership we need to be using v6 or whatever it's gotten to now. That's a giant project, and one that keeps going every 6 months unless you're ok with eventually being on outdated, unsupported versions of the framework. With a microfrontend you just refactor a piece at a time, not the whole thing.
The Angular 1 to 2 split was the most dramatic, but all frameworks introduce breaking changes at some point that prevent upgrades.
With a microfrontend, if every component is on v1, and the new component is on v2 you can lazily update all other components as time allows without a giant refactor or greenfielding it from scratch (while potentially having a larger download size for a time)
The different teams and different framework examples of the microfrontend site get in the way I think. The real point should be the ability to get away from using frameworks for everything (so obviously Dan isn't going to like it... Not in a conspiracy sort of way, but in a "React is the only answer" sort of mindset), the flexibility to use them if you actually NEED them, and the ability to have disparate pieces coexist on a page in spite of the fact that the developer in 2019 didn't care (or know) what the developer in 2025 was going to do.
Also, just like on the backend, where in theory you could have Go, Node, Python and Java services, you could do the same on the frontend with the big three. Unless it's a google-sized shop, there will probably be pressure if not outright instructions to stick to a stack front and back in most cases.
Ok, time to finish the video... Only 17 minutes in and I wrote a novel... Sorry Lucas. Watch, you'll make all these points 5 minutes from now and I'll look like a dummy haha!
Obligatory perspective: I've been using Stenciljs to compile my components... Maybe that's coloring my view of the ease/difficulty of building a microfrontend
Hey, thanks for giving your perspective! Although we definitely have disagreements I'm really glad that we can discuss this issue, and I'd love to understand your side better.
But the REAL benefits are avoiding framework lock-in and stability. If I build a microfrontend component (spec compliant web component) and package it up into an npm package, that component lives forever.
I think that this definitely could be true, but I also see there being implicit feature dependencies that arise as a result of business decisions. Very seldom can I design a component that I can just package up to live forever and work forever, either in terms of its dependencies or in its business context. For example, even if my component comes bundled with Angular x.x.x, it's almost certain I will have to update it at some point to meet updated business requirements, and at that point I see maintaining two versions of Angular as technical debt as opposed to a benefit.
Also, just like on the backend, where in theory you could have Go, Node, Python and Java services, you could do the same on the frontend with the big three. Unless it's a google-sized shop, there will probably be pressure if not outright instructions to stick to a stack front and back in most cases.
I definitely address this in the video. My point is that using too many technologies may and most likely will cause unnecessary maintenance and tech debt issues to arise in the long term.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
The first thing I will say is: Imagine if that component didn't have Angular, or React or Vue or jQuery (haha). That's the dream. No external dependencies, just a vanilla web component that meets the spec and therefore will be supported for years to come. Then we write once, install anywhere that we need it (Which is, again, a design system, not an application... think bootstrap/ionic v4/carbon/Material design, only implemented as web components... which Ionic already did).
If I compose my micro-frontend from those components (Into a bigger component) then I don't even HAVE a framework to download to the user's browser.
That said, let's say there is a need for a framework inside of that larger, composed component, or even one of the design-system components. That need is specific to that component, and doesn't impact the other components making up the app. So now the upgrade cycle is contained in this smaller piece.
I think Angular and Vue already provide an optimized (IE: Smaller) versions of their frameworks for use inside of a component, and React is already tiny (but I think they may have or are working on a component solution as well). This simply allows us to use the framework when we NEED it, instead of a default requirement. Getting away from the forced requirement is why it's intriguing, not building with multiple frameworks.
If a business requirement forces me to upgrade the framework, that's GREAT! Now I update this one portion of my application, and as long as I keep the previous data contract with the rest of the application, I can rest assured that there are no side-effects from the change.
For the second quote... I'm not sure you got my intention (which is my fault from a clarity perspective!) I'm making the same point. You CAN do this on the backend with micro-services (Sidenote: You make valid points in the video that micro-services have a certain hype behind them, and monoliths are NOT automatically bad, I just want to note that I appreciate and agree with that sentiment and I think it applies to micro-frontends as well).
BUT:
I'm not saying you should. In fact I recently made a comment on this very issue where I specifically said you CAN, but you shouldn't haha: dev.to/scott_yeatts/comment/bje6
Stack/technology cohesion is an organizational/leadership issue. If I interviewed with a shop that told me they had Go, Node, Python and Java in the backend I'd give them the side-eye. Same if they told me they had React, Vue AND Angular in the frontend, micro-frontend or not. The point of that comment is that unless you're Google, choosing a technology and not letting developers do whatever they want is important. If you then have a standard (Use framework X where it's needed), a version (We use version x.x.x of the standard framework) and track upgrade cycles (component X needed version x.x.y for a specific reason, we need to start upgrading component y and z so we're not dependent on version x.x.x anymore), then micro-frontends are an excellent tool for creating a separation of concerns similar to that of micro-services on the backend.
Final thought (sorry for the novels, I just get interested in these discussions, especially when they aren't flame-wars, which is why I love this site :D). Micro-frontends DO take longer to build initially, just like micro-services. The benefit shows up later, in maintenance, similar to how unit tests don't make you go faster NOW, but they speed you up six months later when you don't realize you just broke something. Micro-frontends isolate your changes from unintended consequences. If time to market is your primary concern, build a monolith on the backend and a traditional framework SPA on the frontend. If the flexibility of your completed application is primary, micro-frontends might be the way to go. Right tool for the job and all.
Final, FINAL thought: Loved the video. It felt a little like a reaction video (reading the material as you go) vs a breakdown of the concept after an implementation and investment in the concept (which a lot of the authors you looked at seemed to have done).
That initial reaction is SUPER important to the community, because if I THINK an idea is great and I invest a lot of time proving it's great, then I'm not presenting an honest assessment. I want (even NEED) to be right. The best way to avoid a cargo cult is to have people look at ideas with fresh eyes and honestly assess the ideas behind it. So thanks for looking at it!
Micro-frontends isolate your changes from unintended consequences.
I think that isolating changes from unintended consequences is incredibly important, so I think we definitely agree on principle.
In terms of practice, I'm willing to say that there are different tools for different jobs. I'm also willing to grant that micro frontends could potentially be one of these tools; however, I do have reservations about their potential misuse and/or abuse, and also the other alternatives that may exist for any given solution.
Thank you for taking the time to watch my video, and I appreciate the dialogue!
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
No, thank you! You didn't have to engage with the discussion and you did!
I think it IS a case of different tools for different jobs, and I don't think micro-frontends should be used in every project.
I also think they can be misused and hamper development (I've had that experience... I built my components like a design system at first and that mistake caused the build process to be sub-optimal).
Getting an honest reaction to the concept and an honest assessment of the problems involved is what will push the engineering community to avoid hype-driven development. Your podcast and others like it are vitally important to the community. Thank you for doing it (I'd never have the guts to do what you're doing haha!)
I had a similar experience based on what Scott described.
On my first job, which lasted for 7-8 months, I migrate 4 portals written in flask and Jinja built on top of OpenErp to AngularJS.
On one another project,I initially developed a video Q&A based social networking site in AngularJS, migrated it to AppShell architecture, which served SSR ejs templates from express server, we used jQuery intensively for all the interactions and single page look and feel.
Performance was mind blowing and learning experience was tremendous for me.
On my fourth job, Spent 3 years writing spa in angular1.x, decided to migrate to reactjs, however neither the management nor the time provided a luxury of creating a parallel team to migrate the whole product into reactjs or any modern spa framework.
I have described my journey of breaking down the monolithic spa into service oriented frontend here.
This approach has helped us significantly to iron some of the issues, such as develop, release and deploy each product vertical independently.
After implementation of this model,I have seen tremendous improvement in developing and delivering new applications in minimal cost and shortest time to market.
This approach has also made our front-end architecture agnostic to low level implementation details like UI library or framework such as react vs vue or if something better comes in the future.
I dont get it, isnt it obvious why this is a bad idea? If you need to have v1 and v2 loaded at the same time in your webpage, your webpage just became x2 more bloated. Doesnt that instantly disqualify the idea of microfrontends? Pretty sure it does. Oh sure, if you just want components to sit on github then by all means, call them whatever you want. But surely the entire point is to use any component you like on the same webapp/page. Then it becomes much more bloated.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
looks at it as-if that moment in time is the end-state.
MFE's don't advocate for the end-state to be multiple components all running different versions of the same framework. They add the capability, and I think this is where some of the confusion and fear of the concept comes from.
There's also the assumption of bloat. That assumption comes from a decade of top-heavy frameworks that download everything plus two kitchen sinks just to get to "Hello World". Keep in mind that the dream (mine at least) is that we don't need a framework, because the spec and browsers have caught-up. I can componentize and separate concerns inside of a FE app right now in Vanilla JS.
Angular, React and Vue are no longer necessary, but they provide a lot of convenience features and opinionated approaches that help larger teams to standardize their systems.
As I said in an earlier comment, imagine a world where the framework only gets used in the places it's necessary.
If you then have a standard (Use framework X where it's needed), a version (We use version x.x.x of the standard framework) and track upgrade cycles (component X needed version x.x.y for a specific reason, we need to start upgrading component y and z so we're not dependent on version x.x.x anymore), then micro-frontends are an excellent tool for creating a separation of concerns similar to that of micro-services on the backend.
Just like technology can't be a solution for organizational issues (and I don't think that's a good application of MFEs either), you can't depend on technology to provide technical leadership and standards. The video's point about Guilds (from the Spotify model) is dead-on. You have to have a person or group from the teams whose job is technical cohesion. So if group "A" says "We need to ramp version on the standard framework to X" and group "D" and "T" pipe up with "We use the standard framework as well", then those teams need to build an upgrade plan to all be on the same version to minimize bloat, but teams "B", "C" and "E-S" don't need to be involved, and the three teams can develop a plan together. For a few weeks or even months there may be two different frameworks downloaded to users.
This is where things outside MFEs come into play. Does your performance budget allow for the slowdown caused by the two framework versions? Is there tree-shaking that could smooth the issue? Is the performance impact noticeable on fast connections? On slow connections? Are we using the smallest possible file-size that the framework allows? These are good practices the team should be performing anyway, and can inform whether or not the teams need to coordinate releases to avoid the version split or if they can upgrade independently.
But the end-state of the application is that there is one version of the framework downloaded to the user's browser. Right now that's the only option available to us. MFE's allow us a new capability to handle upgrade cycles at a smaller, more manageable scale, and could even be considered a new paradigm away from framework monoliths that most developers have gotten comfortable with over the last decade.
Remember how developers recoiled in terror at the thought of SPAs (Bloat, there's no way you can download ALL of the JS for every page, it'll be too big)? JSX (HTML generated from JS. It's dangerous and insecure, and it's flipping the stability pyramid on its head!)? TypeScript (JavaScript is duck-typed by design, this is just trying to make JS into Java-lite)?
I think this reaction to MFEs seems similar, because they do fly in the face of "how we've always done it (for the last 10 years)" and still might be proven to be a bad idea in the long run. But instantly disqualifying it because of the new capability it provides (and fears of how it might be misused) could block a legitimate path to simplifying day to day development.
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.
I'm 17 minutes in and getting really distracted by the fact that the point is getting missed.
I've been building a microfrontend for almost a year, and there are good points made around app-size/company size, etc.
But the REAL benefits are avoiding framework lock-in and stability. If I build a microfrontend component (spec compliant web component) and package it up into an npm package, that component lives forever.
I don't have to go back and modify it every time a new version of the framework comes out.
In addition, think of it from the perspective of going framework-less, not in terms of the frameworks (as the microfrontend site example is pretty tortured). The whole POINT of these frameworks, going back a decade, was to allow us to separate concerns and componentize (work in the average jQuery app circa 2008 and you'll know what I mean haha). This isn't about using all the frameworks, this is about not needing them anymore.
If everything is a purely contained component that can run on its own completely independently, then you have a design system, not an application.
If you then compose a set of components into a larger "frame" component, and that frame has an API that it calls on the backend to where each microfrontend is a vertical slice of the application, then it becomes ridiculously trivial to make changes.
You CAN do that with a good component model. Now, change the framework version in an app without a microfrontend.
Example from the real world: Spend five years writing an Angular 1.X site with a bunch of element directives. Now you've finally convinced leadership we need to be using v6 or whatever it's gotten to now. That's a giant project, and one that keeps going every 6 months unless you're ok with eventually being on outdated, unsupported versions of the framework. With a microfrontend you just refactor a piece at a time, not the whole thing.
The Angular 1 to 2 split was the most dramatic, but all frameworks introduce breaking changes at some point that prevent upgrades.
With a microfrontend, if every component is on v1, and the new component is on v2 you can lazily update all other components as time allows without a giant refactor or greenfielding it from scratch (while potentially having a larger download size for a time)
The different teams and different framework examples of the microfrontend site get in the way I think. The real point should be the ability to get away from using frameworks for everything (so obviously Dan isn't going to like it... Not in a conspiracy sort of way, but in a "React is the only answer" sort of mindset), the flexibility to use them if you actually NEED them, and the ability to have disparate pieces coexist on a page in spite of the fact that the developer in 2019 didn't care (or know) what the developer in 2025 was going to do.
Also, just like on the backend, where in theory you could have Go, Node, Python and Java services, you could do the same on the frontend with the big three. Unless it's a google-sized shop, there will probably be pressure if not outright instructions to stick to a stack front and back in most cases.
Ok, time to finish the video... Only 17 minutes in and I wrote a novel... Sorry Lucas. Watch, you'll make all these points 5 minutes from now and I'll look like a dummy haha!
Obligatory perspective: I've been using Stenciljs to compile my components... Maybe that's coloring my view of the ease/difficulty of building a microfrontend
Hey, thanks for giving your perspective! Although we definitely have disagreements I'm really glad that we can discuss this issue, and I'd love to understand your side better.
I think that this definitely could be true, but I also see there being implicit feature dependencies that arise as a result of business decisions. Very seldom can I design a component that I can just package up to live forever and work forever, either in terms of its dependencies or in its business context. For example, even if my component comes bundled with Angular x.x.x, it's almost certain I will have to update it at some point to meet updated business requirements, and at that point I see maintaining two versions of Angular as technical debt as opposed to a benefit.
I definitely address this in the video. My point is that using too many technologies may and most likely will cause unnecessary maintenance and tech debt issues to arise in the long term.
Thanks for the kind (and thoughtful) reply :D
The first thing I will say is: Imagine if that component didn't have Angular, or React or Vue or jQuery (haha). That's the dream. No external dependencies, just a vanilla web component that meets the spec and therefore will be supported for years to come. Then we write once, install anywhere that we need it (Which is, again, a design system, not an application... think bootstrap/ionic v4/carbon/Material design, only implemented as web components... which Ionic already did).
If I compose my micro-frontend from those components (Into a bigger component) then I don't even HAVE a framework to download to the user's browser.
That said, let's say there is a need for a framework inside of that larger, composed component, or even one of the design-system components. That need is specific to that component, and doesn't impact the other components making up the app. So now the upgrade cycle is contained in this smaller piece.
I think Angular and Vue already provide an optimized (IE: Smaller) versions of their frameworks for use inside of a component, and React is already tiny (but I think they may have or are working on a component solution as well). This simply allows us to use the framework when we NEED it, instead of a default requirement. Getting away from the forced requirement is why it's intriguing, not building with multiple frameworks.
If a business requirement forces me to upgrade the framework, that's GREAT! Now I update this one portion of my application, and as long as I keep the previous data contract with the rest of the application, I can rest assured that there are no side-effects from the change.
For the second quote... I'm not sure you got my intention (which is my fault from a clarity perspective!) I'm making the same point. You CAN do this on the backend with micro-services (Sidenote: You make valid points in the video that micro-services have a certain hype behind them, and monoliths are NOT automatically bad, I just want to note that I appreciate and agree with that sentiment and I think it applies to micro-frontends as well).
BUT:
I'm not saying you should. In fact I recently made a comment on this very issue where I specifically said you CAN, but you shouldn't haha:
dev.to/scott_yeatts/comment/bje6
Stack/technology cohesion is an organizational/leadership issue. If I interviewed with a shop that told me they had Go, Node, Python and Java in the backend I'd give them the side-eye. Same if they told me they had React, Vue AND Angular in the frontend, micro-frontend or not. The point of that comment is that unless you're Google, choosing a technology and not letting developers do whatever they want is important. If you then have a standard (Use framework X where it's needed), a version (We use version x.x.x of the standard framework) and track upgrade cycles (component X needed version x.x.y for a specific reason, we need to start upgrading component y and z so we're not dependent on version x.x.x anymore), then micro-frontends are an excellent tool for creating a separation of concerns similar to that of micro-services on the backend.
Final thought (sorry for the novels, I just get interested in these discussions, especially when they aren't flame-wars, which is why I love this site :D). Micro-frontends DO take longer to build initially, just like micro-services. The benefit shows up later, in maintenance, similar to how unit tests don't make you go faster NOW, but they speed you up six months later when you don't realize you just broke something. Micro-frontends isolate your changes from unintended consequences. If time to market is your primary concern, build a monolith on the backend and a traditional framework SPA on the frontend. If the flexibility of your completed application is primary, micro-frontends might be the way to go. Right tool for the job and all.
Final, FINAL thought: Loved the video. It felt a little like a reaction video (reading the material as you go) vs a breakdown of the concept after an implementation and investment in the concept (which a lot of the authors you looked at seemed to have done).
That initial reaction is SUPER important to the community, because if I THINK an idea is great and I invest a lot of time proving it's great, then I'm not presenting an honest assessment. I want (even NEED) to be right. The best way to avoid a cargo cult is to have people look at ideas with fresh eyes and honestly assess the ideas behind it. So thanks for looking at it!
I think that isolating changes from unintended consequences is incredibly important, so I think we definitely agree on principle.
In terms of practice, I'm willing to say that there are different tools for different jobs. I'm also willing to grant that micro frontends could potentially be one of these tools; however, I do have reservations about their potential misuse and/or abuse, and also the other alternatives that may exist for any given solution.
Thank you for taking the time to watch my video, and I appreciate the dialogue!
No, thank you! You didn't have to engage with the discussion and you did!
I think it IS a case of different tools for different jobs, and I don't think micro-frontends should be used in every project.
I also think they can be misused and hamper development (I've had that experience... I built my components like a design system at first and that mistake caused the build process to be sub-optimal).
Getting an honest reaction to the concept and an honest assessment of the problems involved is what will push the engineering community to avoid hype-driven development. Your podcast and others like it are vitally important to the community. Thank you for doing it (I'd never have the guts to do what you're doing haha!)
I had a similar experience based on what Scott described.
On my first job, which lasted for 7-8 months, I migrate 4 portals written in flask and Jinja built on top of OpenErp to AngularJS.
On one another project,I initially developed a video Q&A based social networking site in AngularJS, migrated it to AppShell architecture, which served SSR ejs templates from express server, we used jQuery intensively for all the interactions and single page look and feel.
Performance was mind blowing and learning experience was tremendous for me.
On my fourth job, Spent 3 years writing spa in angular1.x, decided to migrate to reactjs, however neither the management nor the time provided a luxury of creating a parallel team to migrate the whole product into reactjs or any modern spa framework.
I have described my journey of breaking down the monolithic spa into service oriented frontend here.
This approach has helped us significantly to iron some of the issues, such as develop, release and deploy each product vertical independently.
After implementation of this model,I have seen tremendous improvement in developing and delivering new applications in minimal cost and shortest time to market.
This approach has also made our front-end architecture agnostic to low level implementation details like UI library or framework such as react vs vue or if something better comes in the future.
Do you have real example? Because this tale about migration from AngularJS to Angular sounds weird.
I dont get it, isnt it obvious why this is a bad idea? If you need to have v1 and v2 loaded at the same time in your webpage, your webpage just became x2 more bloated. Doesnt that instantly disqualify the idea of microfrontends? Pretty sure it does. Oh sure, if you just want components to sit on github then by all means, call them whatever you want. But surely the entire point is to use any component you like on the same webapp/page. Then it becomes much more bloated.
It's a tradeoff, but
looks at it as-if that moment in time is the end-state.
MFE's don't advocate for the end-state to be multiple components all running different versions of the same framework. They add the capability, and I think this is where some of the confusion and fear of the concept comes from.
There's also the assumption of bloat. That assumption comes from a decade of top-heavy frameworks that download everything plus two kitchen sinks just to get to "Hello World". Keep in mind that the dream (mine at least) is that we don't need a framework, because the spec and browsers have caught-up. I can componentize and separate concerns inside of a FE app right now in Vanilla JS.
Angular, React and Vue are no longer necessary, but they provide a lot of convenience features and opinionated approaches that help larger teams to standardize their systems.
As I said in an earlier comment, imagine a world where the framework only gets used in the places it's necessary.
Just like technology can't be a solution for organizational issues (and I don't think that's a good application of MFEs either), you can't depend on technology to provide technical leadership and standards. The video's point about Guilds (from the Spotify model) is dead-on. You have to have a person or group from the teams whose job is technical cohesion. So if group "A" says "We need to ramp version on the standard framework to X" and group "D" and "T" pipe up with "We use the standard framework as well", then those teams need to build an upgrade plan to all be on the same version to minimize bloat, but teams "B", "C" and "E-S" don't need to be involved, and the three teams can develop a plan together. For a few weeks or even months there may be two different frameworks downloaded to users.
This is where things outside MFEs come into play. Does your performance budget allow for the slowdown caused by the two framework versions? Is there tree-shaking that could smooth the issue? Is the performance impact noticeable on fast connections? On slow connections? Are we using the smallest possible file-size that the framework allows? These are good practices the team should be performing anyway, and can inform whether or not the teams need to coordinate releases to avoid the version split or if they can upgrade independently.
But the end-state of the application is that there is one version of the framework downloaded to the user's browser. Right now that's the only option available to us. MFE's allow us a new capability to handle upgrade cycles at a smaller, more manageable scale, and could even be considered a new paradigm away from framework monoliths that most developers have gotten comfortable with over the last decade.
Remember how developers recoiled in terror at the thought of SPAs (Bloat, there's no way you can download ALL of the JS for every page, it'll be too big)? JSX (HTML generated from JS. It's dangerous and insecure, and it's flipping the stability pyramid on its head!)? TypeScript (JavaScript is duck-typed by design, this is just trying to make JS into Java-lite)?
I think this reaction to MFEs seems similar, because they do fly in the face of "how we've always done it (for the last 10 years)" and still might be proven to be a bad idea in the long run. But instantly disqualifying it because of the new capability it provides (and fears of how it might be misused) could block a legitimate path to simplifying day to day development.