In June I've written a post regarding the "State of Microfrontends". This article focused on the technical solutions available and presented some key players as well as a bit of background info. Recognizing that the user side was lacking I published a small survey.
I'm happy that after more than two months and quite some tweets the survey has been closed. The results are now evaluated and I'll try to present them here in the best form possible. Overall, over 300 answers have been registered.
If you think this survey deserves a more suitable (i.e., larger, better prepared) follow up then let me know in the comments. Any contribution is much welcome.
Let's get right into it!
Who Participated
From the answers, it is clear to see that the majority is planning to or already working with microfrontends.
While a fifth is only at the start of their journey with microfrontends (and thus potentially found the article/survey) more than a third feel already fully equipped to fully leverage microfrontends.
Nearly three out of four participants read posts and articles about microfrontends on a regular frequent basis. This matches very well with the participants' knowledge.
What's the background of these participants? Looking at the number of employees of the participants' companies we see that it's quite equally spread. Sure, a third works at quite large corporations with more than one thousand employees, but another third works at smaller companies with less than a hundred workers.
Especially that every ninth participant works at a company with less than 10 people is remarkable. These are either very special projects or agencies working for larger companies. In my case, it's the latter.
A potentially better indicator about the participants' background is the number of frontend developers at one of the microfrontend projects. While there is still a significant portion with more than 100 frontend developers (okay, that really is something requiring microfrontends) four-fifths have less than twenty frontend devs.
There is no strict boundary when microfrontends make sense from a team size point of view. Sometimes two developers may already make it sufficient, sometimes even larger workforces play together perfectly fine without additional modularization.
In the end its a combination of several factors incl. the problem to solve, the organizational structure, the workflow, the communication paths, and the application's architecture.
For a first-hand experience of a company taking into consideration these different factors, read here.
Frameworks or Libraries
So let's get technical. One of the core questions to answer in this survey was if the current technology landscape is fully known and appealing. Does it solve the problem sufficiently? What is potentially lacking?
Microfrontends are not for everyone. While creating or maintaining a (single) microfrontend should be as simple and straight forward as possible, setting up a whole microfrontend solution is among the most difficult tasks in frontend engineering right now. There are just many pieces to keep in mind. And it all starts already with a basic decision: How to do it?
The most basic question is: Do you want to use microfrontends as a SPA from the client-side, or classically server-side rendered? Sometimes, microfrontends are also stitched together in a joint build-process (like in Bit.dev's example case above). There are even variations or combinations of the three. Two thirds, however, agree that the client-side in form of a SPA is the way to do it.
It would be interesting to correlate this with the individual participant's project's industry. For instance, I believe that for webshops or in general eCommerce solutions in general client-side is the least used solution. Here, server-side fully shines. For portals and tools, single-page apps are certainly the way to go.
Likewise, asking for the use of frameworks we see that less than half of the participants used an existing framework. Potentially, the number of "home-grown" solutions that are just perfectly aligned with the project's needs is still large.
One reason for this is the relative age or youth of microfrontends as an architecture pattern. Most projects already started two or three years ago when no real solutions have been on the market.
This also can be seen by the provided ratings of the available solutions. Its a near perfect Gaussian (normal distribution). The essence is that most people regard the currently available solutions as average or mediocre. This, of course, takes only their known solutions into consideration. We would need to dive into correlations to find out how they rate the different frameworks.
So what frameworks do the participants know? From the given list unsurprisingly Single SPA is the most known solution. Mosaic from Zalando comes in second place. Potentially biased through my own distribution Piral is also already known to every fifth participant of the survey.
This does not include tools and platforms that manage independent components, even though they, essentially, offer a compile-time implementation of Micro-frontends (and are not only useful as a helper tool for consistent UI, code reuse, etc.).
The list of frameworks also contained some solutions that are actively marked as outdated or deprecated. This is also one indicator of this fast spinning market that we see here. Microfrontends are still complex and young technology.
Asking the participants about other frameworks or techniques they use we get:
- Pure distribution standards and technologies such as AMD, SystemJS, or iframes.
- Architecture decisions such as vertical/horizontal split, client/edge-side, or server-side composition.
- Tooling based solutions, e.g., Webpack Module Federation, React + Webpack + React Suspense + Dynamic Module Loading + Lerna + Yarn Workspaces.
- Other frameworks/solutions such as UmiJS, icestark, or feature-hub.io.
In general, though, the list above fits well. Especially looking at the other solutions such as UmiJS or icestark it feels that the Asian market is somewhat misrepresented in this survey. Luckily (or unfortunately), it seems that most participants also did not come from that region. For a follow-up survey help to cover the trends worldwide would certainly be much appreciated!
Why Microfrontends
Well, this is a great question, right? After all, wouldn’t a monolith or whatever we built 3 or 4 years ago do it? There must be some (hopefully business-relevant) reasons for using microfrontends.
Ability to use different frontend frameworks but still having SPA UEX.
Quite often we hear that microfrontends are especially great for SPAs as they break the walled garden of a single technology. Is that true? Is the use of multiple technologies really the driver here?
It does not seem so. Certainly, being able to use multiple technologies is nice and quite often demanded, but we should be cautious not to overload the user's browser with too many technologies. Also, who will take care of maintenance here? How to keep up with updates to all the used technologies? More than half just use a single technology and have fewer problems.
Independent, if we use a single or multiple technologies — what should be our primary focus here? Is there a single technology that makes some sense to focus on?
It turns out React is also strong in the microfrontend space. Almost 60% would settle on React. Angular and Vue are tied. This is a bit surprising, as especially Angular is known for being the basis of massive apps.
However, really making a scalable microfrontend solution with Angular is — as it turns out — not so easy. This is in contrast to React, which comes with debatable the most composable component model.
Svelte takes the first spot after the glory three. For me personally, this is not a huge surprise. Svelte is great and due to the compile-to-native-functions approach very nicely fitting for microfrontends.
For our current company architecture, the product is very big and we are trying to implement feature ownership. It is very difficult for instance, when the node modules needs to be updated for everyone. Micro frontend would also ease the QA part.
So if multi-framework is not the most desired advantage — what is it then?
Through the improved modularization, multiple teams can work much better on a single project. In the end, this also reflects in a more rigorous architecture and thus in a better dev experience. The latter, of course, can only be perceived in a large project.
Compared to the quite common monolithic spaghetti a microfrontend solution could be regarded as lightweight and elegant. After all, the different modules should all be focused and rather small/minimal.
The comments also respect the team aspect a lot.
Enabling autonomous teams to work side by side with little coordination
(or to use another good quote here: "Avoid other teams code"), which results in
Faster time to market
due to
Vertical slices of work
alias "Partitioning of application complexity along team and domain boundaries."
Interestingly, the user experience is also seen as a key factor by a third of the developers. For me personally, this is indeed an interesting feature of microfrontends — allowing not only the development to scale better, but also the user experience to be more progressive, too. However, together with the personalization option these two still form the least of seen advantages.
Flexibility to compose the application based on user role. Stability in the amount of code that needs to initially be loaded by the client no matter how large the app/feature set grows. Better development across teams. Ability to leverage the same devops tools for new pieces of the front end, which greatly simplifies rolling out new functionality.
Reasons for Not Using Microfrontends
The survey also had a text field for disadvantages. The most seen ones have been:
- Complexity (tooling, versioning, UX alignment, …)
- Performance (bundle size, loading time, …)
- Multi-framework (knowledge, overhead, …)
- Lack of standards (foundation, CSS isolation, …)
- Testing
- Architecture
One reason why people don't like the currently available solutions is that
Most frameworks and UI libraries assume they're you're only choice and don't integrate well.
This is certainly right. However, in my opinion this is just the reflection that these frameworks definitely serve different purposes and solve different problems. Nevertheless, some level of interoperability could help here.
There was one longer comment that reflected this pretty well:
There does not seem to be a lot of standardization here and there was even less when we set out to build our solution 2 years back. We had to build a custom setup based on our needs. We used standards like AMD modules compiled with Webpack, but all the builds and automation had to be very customized. We got to a great place, but took a lot of work to get here.
Conclusion
Overall, the community seems to be quite happy with the current progress. Despite the obvious issues and complexity of microfrontends in general, progress and use cases seem to advance in the right direction.
What's your opinion? Do you agree or are my conclusions off?
Top comments (2)
Nice detailed analysis 👍🏻 However, since doing research on micro frontends before myself, I have one question:
How did you ensure to achieve a heterogenous sample so that the sample also includes people that have never heard of micro Frontends or are not interested in? I imagine that mostly people that have some kind of relation to micro frontends answer such a study, so I‘m not sure whether such a study can capture the whole picture.
Keep up the good work. Stuff like this brings the field of microfrontends forward 👍🏻
Great question. As remarked this study is certainly biased as I was the primary person to not only write the questions, but also to promote it. Thus a larger fraction will have heard about microfrontends beforehand.
Note, however, that the study was not about the adoption in general, rather how they are being used from a technical perspective. Thus having more qualified participants was certainly fine.
For next year my goal would be to find 5-10 interested peers to create a much larger, more detailed, and less biased study.
Any help would be appreciated!