by mmmeff on 6/18/20, 8:13 PM
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.
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.
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.
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.
by logicalmonster on 6/18/20, 6:33 PM
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.
by bob1029 on 6/18/20, 8:12 PM
This is basically micro-services ideology but applied to the front-end. To me, all of this reads as:
"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."
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.
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.
by BossingAround on 6/18/20, 6:38 PM
Honestly, that looks like the most horrifying piece of tech that I really wanna learn and try...
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.
And yet I feel like I wanna try that for our next project.
by Vinnl on 6/18/20, 7:02 PM
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.
by mrsharpoblunto on 6/18/20, 8:53 PM
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.
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...
by tobr on 6/18/20, 6:25 PM
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.
by JMTQp8lwXL on 6/18/20, 7:03 PM
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.
by ironmagma on 6/18/20, 7:38 PM
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.
by rado on 6/18/20, 8:14 PM
A poorly organised company will always be a poorly organised company regardless of the tools it uses.
by liminal on 6/18/20, 7:00 PM
This seems like something useful that I hope to never have to debug
by bauerd on 6/18/20, 6:37 PM
So this is like Server Side Includes (SSI) but with shared state and built on top of JS modules?
by denysonique on 6/18/20, 6:36 PM
Does it finally work magically out of the box like Parcel does?
by kentaadc on 6/24/20, 8:59 AM
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.
by neals on 6/18/20, 7:32 PM
Like <Frame/> but better!
by i_like_robots on 6/18/20, 8:23 PM
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.
We've been able to achieve this to good effect using Webpack 4 with some hackery (https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-co...) 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.
by globular-toast on 6/18/20, 8:30 PM
This title was quite hard for me to parse. I was thinking, what is Micro-front and why is it ending?
by greenie_beans on 6/18/20, 11:56 PM
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?
by ryanmarsh on 6/18/20, 6:52 PM
Nice. Now all the clients pretending to develop microfrontends (by breaking up the repos) but shipping one big js bundle can stop fucking lying now.
by KayL on 6/18/20, 6:19 PM
what software used to create the diagrams in the article?