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!)
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.
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!)