there's a possibility using multiple frameworks makes sense.
I think this is a case of "just because you, can doesn't mean you should"–the standing wisdom is to settle on a unified infrastructure in order to minimize the negative impact on end user experience.
For example, while not related to micro frontends in particular, Etsy standardized on Preact to streamline their development efforts rather than going forward with a Preact/React split.
Microservices and micro frontends are largely a technical solution to organizational challenges of large scale systems where complexity is used to manage complexity - aiming to shift development complexity (managed by the customer) to operational complexity (managed by the service provider).
When it comes to micro frontends, it’s been a longer process to acceptance
Perhaps because micro frontends tend to benefit organizations upwards of a certain scale and at a certain level of maturity/stability (example: AutoScout24)
From that perspective the association between a "flashup" (presumably derived form "startup") and micro frontends could be premature. As Adam Ralph in "Finding Your Service Boundaries" observes:
"Now is there anyone here working in a startup or a startup-ish kind of environment? Yeah it's just a few hands going up. Alright so for you guys I've got a little bit of bad news. If you're getting excited about this kind of stuff and you think this is interesting be very wary of using it too early in this, in a startup phase. So the problem is that startups are very good example of where you might not want to use this, at least initially because startups don't know what their businesses are yet."
The problem with microservices (and by extension micro frontends) is that boundaries are fairly expensive to change, at least in comparison to a modular monolith. Within an established organization the various bounded contexts within their domain should be relatively stable—for startups that is not typically the case.
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 think this is a case of "just because you, can doesn't mean you should"–the standing wisdom is to settle on a unified infrastructure in order to minimize the negative impact on end user experience.
For example, while not related to micro frontends in particular, Etsy standardized on Preact to streamline their development efforts rather than going forward with a Preact/React split.
Microservices and micro frontends are largely a technical solution to organizational challenges of large scale systems where complexity is used to manage complexity - aiming to shift development complexity (managed by the customer) to operational complexity (managed by the service provider).
Perhaps because micro frontends tend to benefit organizations upwards of a certain scale and at a certain level of maturity/stability (example: AutoScout24)
From that perspective the association between a "flashup" (presumably derived form "startup") and micro frontends could be premature. As Adam Ralph in "Finding Your Service Boundaries" observes:
"Now is there anyone here working in a startup or a startup-ish kind of environment? Yeah it's just a few hands going up. Alright so for you guys I've got a little bit of bad news. If you're getting excited about this kind of stuff and you think this is interesting be very wary of using it too early in this, in a startup phase. So the problem is that startups are very good example of where you might not want to use this, at least initially because startups don't know what their businesses are yet."
The problem with microservices (and by extension micro frontends) is that boundaries are fairly expensive to change, at least in comparison to a modular monolith. Within an established organization the various bounded contexts within their domain should be relatively stable—for startups that is not typically the case.