Microfrontends should be a last resort

It means the interfaces become important and you can work on the internals in parallel.

I think microfrontends are the ultimate extension of what I call "the myth of code reuse".

Everyone thinks because they can create "small reusable slices" of full frontend code that this comes for free without a load of problems that get in the way of the mythical land. The only issue is everyone who has tried microfrontends is universally full of regret.

Other attempts at this are:

1) having an enforced centralised library of components (this just about works) - how this is managed and the engagement with other teams is critical.

2) turn everything into an npm package and create version hell at the end of a sprint as hundreds of devs try to version bump everything and the main package.json all at the same time.

3) free for all with moving people regularly between teams. This is the best solution because best practices automatically filter their way through each team through the people and everyone learns and gets on with each other in a human way that allows real collaboration.

4) splitting vertically rather than by components so one team does the search UI another does the homepage another does the product detail etc. but hopefully in the same technology!

Or you could probably just reduce the number of people adding pointless features to your ecommerce site... Ah there is five of you and you did microfrontends didn't you, I can't and won't help you then :-/

> knowing about them was his primary signal for someone's overall competence

I don't know if it's the primary signal, but I think you need a balanced team. It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community. But you have to be careful that person isn't blindly trying to apply every trend in your product, e.g. resume driven development.

I don't blame conferences for that. Conferences should (often) be a good place for more out there ideas, more experiments, experience sharing with new ideas, etc. It's the fault of viewers for thinking "I'm gonna do this thing without really evaluating it for my use case", which is a generally large problem in tech.

Most of the implementations of MFEs I've seen are reliant on webpack or Single-SPA (which by default uses webpack under the hood).

vite, esbuild, parcel etc. have not adopted anything around this.

To me, that says that those putting out the nuts and bolts work that having been leading this space for several years either haven't spent alot of time evaluating them, or have found them overly complex for what they are, or perhaps think there is a better way to accomplish their goals.

I'm not sure MFEs are the best tech, to be honest. I've seen demos where it seems to be an addition (bootstrapping speed, neat tricks with routing etc.) but I've never seen them demonstrated in practice. I'm on a team now that is adopting MFEs and our payload is somehow considered acceptable at 8 MB. Given this is a behind-the-login app, I think somewhere between 300-500KB bootstrapping and getting to interactive with the rest lazy loaded is fine, but 8 MB to boot the app seems like we aren't doing even basic optimizations (I unfortunately do not have the control I wish I had on this)

I'm really unsure about MFEs, they seem like something looking for a problem in practice. They certainly appear hard to get right