Hacker News new | ask | show | jobs
by pandler 2254 days ago
We make heavy use of peer dependencies, so microfrontends rarely end up actually bundling their own dependencies. Build tools like rollup help with that.

It’s not a silver bullet and requires A bit of overhead. I’m interested too to hear how other people manage the problem.
1 comments
Etheryte 2254 days ago
That is true, however one of the main arguments for micro frontends is the freedom to use anything: one team can use React, the other Vue, one uses this table library, the other another. If you don't do that, micro frontends offer very little in benefit as far as I see. If you do do that, what you're left with is pretty much regular architecture, just in separate repos and harder to keep in sync.
link
FlorianRappl 2254 days ago
Personally, I think this is a myth (https://blog.bitsrc.io/11-popular-misconceptions-about-micro...).

Most our projects where microfrontends have been actively demanded (and we did now quite a lot of them) did not come up due to use of multiple frameworks. Yes, it is possible to use multiple technologies, but quite often there is key technology in place anyway. E.g., one of our clients had a huge pattern library written in React and demanded all microfrontends to be written in React.

So why then microfrontends at all? Well, all parts are still independent from each other, i.e., independently developed and deployed. Our client has multiple teams and like that these teams can just work in their own pace using a few guiding principles that have been given by the solution architecture.

link
pandler 2254 days ago
FYI your link is broken.

Agreed, the only mention of using different technology has come up in the current project is in discussions of Typescript vs plain JavaScript. That’s been the only bring-your-own-technology for the most part, since we’ve standardized on React and some shared libraries like Lodash.

We’ve primarily benefitted from the forced feature and team isolation (aka domain boundaries if you would), plus it gives teams more granular control over their deployments. So, pretty much just what you described.

Another benefit has been our ability to build once and share features across different applications, since we have a few of those for reasons. Teams can build out different “views” (roughly) for different use cases on different apps which share the core functionality.

link