You know that an architecture or pattern is no longer a secret sauce when suddenly an article pops up at Martin Fowler's page. This happened in the past with microservices and it also happened this year with microfrontends.
What is the microfrontend architecture and why are so many people enthusiastic about it? For many people a microfrontend architecture is the frontend equivalent of the microservice architecture for backend. As such instead of developing a monolith service (= service that has multiple responsibilities / capabilities) many microservices should be implemented. Likewise, instead of creating a monolith client (= application that contains all functionality that should be visible to the end-user) many individual modules should be implemented.
As it turns out this already represents the core difference. While a microservice is indeed self-contained and to some degree independent, a microfrontend will always be part of a larger application - at least from a UX point of view. Therefore, all the different microfrontend modules accessible by end-users will - in one combination or another - be loaded into the user's browser. Hence the question: Does it really make sense to put the same principles that have been applied for microservices to microfrontends?
Clearly, the answer must be no. While its nice to use React for microfrontend A and Angular for microfrontend B, such a decision should have a historic background. Having multiple frameworks in the same application will come at multiple sacrifices - most notably performance and consistency. Furthermore, to ensure a common denominator a microfrontend requires a so-called application shell.
An application shell can be thought of as an application without specific features. It may have a layout, a menu structure (without content), logo, footer, ... everything except very specific content or features. All the features come in form of modules, which are then loaded dynamically for the current user - making the experience truly personal and allowing to decouple rules (who can access what) from features (what is specifically done by this). Regarding rights management - this is the salvation we'd hoped for. Backend is still king, but now as backend decides what frontend modules to deliver we only get what we could also use.
Would I personally start with a microfrontend to begin with? It depends. Potentially no. If I would know its a larger application that will only grow - where the features will be provided by multiple developers (even teams), probably even external developers - then the answer is clearly yes. It's a nice pattern.
The in my opinion best solution out there is Piral. It's a microfrontend framework for React. Individual modules could be also written with other frameworks. It has a lean start being serverless-first and developer-first. Even better, from debugging to deploying - everything just works without a large configuration or anything.
Will microfrontends have a great future? I think so - but only if people stop thinking of microfrontends as a solution for "I can use multiple frameworks now" or "I need 5 backend services to get anything done - but never debugging".