We already kind of solved this problem at IMDb using Webpack 3 and 4 (with tons of hackery). It was, all things considered, a terrible idea.<p>We ended up with a web page with 10 nearly identical sections implemented 10 different ways by 10 different developers across 10 different git repositories.<p>Micro-frontends are cancer, please don't fall for it. You can get much more done for less with a single webserver and a graphQL service, not matter your project's scope.<p>No front-end on earth needs multiple teams to build it - if it does, your product is convoluted and needs to be split up and/or simplified.
Maybe this is good and useful for some people: but to me it feels like a continuation of the dark slide that frontend tooling is going on. Way overcomplicated, likely brittle and buggy, significant barriers to just sitting down and building stuff.
This is basically micro-services ideology but applied to the front-end. To me, all of this reads as:<p>"We couldn't agree on a programming language, framework, or set of common development practices, so everyone gets their own individual silo and never has to worry about what everyone else is doing."<p>Does anyone pay attention to the organizational problem that underlies all of this? You have to agree as a team on this stuff. Microservices is not a way to solve a technical problem, but a way to bandaid an organizational/people problem. You simply couldn't get 2 different front-end or back-end teams to agree on some policy or framework, so now you put an explicit rift between them with this microservice bs.<p>We did monolith->micro-services->monolith. I will rewrite a system from scratch before i put it into a leaky box and try to wrap an API around it ever again. You can try to sell this as some sort of way to migrate away from legacy without rewriting code but that is a bullshit siren song that is never true in any reality. You will likely save more time over the long haul building 1 coherent system (both frontend and backend). Keeping legacy around and pushing it further and further into container inception is not a rational technical solution if you actually want to pay down your technical debt at any point.
Honestly, that looks like the most horrifying piece of tech that I really wanna learn and try...<p>In my org, most teams that need it have like one front end dev that's shared among three other teams, and like one or two people who can hammer out some React and don't hate JS to help out with most of the stuff. I suspect this would be an utter madness for that kind of a team.<p>And yet I feel like I wanna try that for our next project.
The goal of micro-frontends (different teams being able to deploy "their" parts of an application) is nice and all, but I still don't see how this is going to work when the shared modules release breaking changes. So now all those different teams that work on different parts of the same applications will still need to do one massively coordinated release in which they all migrate to the newer version at the same time, and a single team delaying things can put the work of all other teams on hold.
Can we please stop overcomplicating the terminology around frontend architecture? The whole Isomorphism craze was bad enough - lets not make this stuff more complex than it needs to be and create confusion by over-loading existing terms like containers.<p>Whats being proposed here are dynamically linked shared libraries, they expose some functionality & also consume dependencies (that may be shared). Theres no need to be talking about containers, federation, orchestration etc...
Of all the possible ways to write it, “Micro-front ends” definitely isn’t the right one. I thought it was about Webpack 5 dropping support for something.
I opened a PR to upgrade my project to webpack 5 in 2019. Still haven't merged it since Webpack 5 still isn't released. If they have no further breaking changes, they ought to release and do a 5.1 with further non-breaking new functionality.
The Webpack dev team's time would be much better spent on making their code strongly typed, with configuration especially having a strong type definition. We need less Webpack to deal with, not more.
Please change my mind: I think that sharing modules on the run is not related on microfrontends. Actually what you can achieve with module federation it's achievable with npm modules. The main difference is that are accessible at run time and that them are sharing common dependencies. But it would be a hell to handle deployment and breaking changes.
I'm hoping that module federation will enable multiple, separately deployed services to reuse assets so that users moving between those services may do so without redownloading the same things over and over.<p>We've been able to achieve this to good effect using Webpack 4 with some hackery (<a href="https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-content-hashes.html" rel="nofollow">https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-co...</a>) but I'd love to be able to point to something documented and official instead... this sort of looks like it might meet this need. Fingers crossed.
Micro-front ends sound like a bad idea, and exactly like the sort of thing our architects would think is a good idea. Does anybody know of any horror story blog posts so I can show my manager, just in case?