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