Patrick, a friend of mine in the web development industry, recently alerted me to the existence of the micro frontend design pattern, and specifically the mini-Twitter-storm it's generating:
Not to be partial, there are also many on the other side of the fence arguing for this pattern:
I sat down with Patrick and we explored this issue in-depth, evaluating both sides of the argument. You can find the whole video attached below:
Happy coding!
This is the first episode of Tech Red Pill, a podcast where we talk and share our opinions on pressing issues and the latest news in the technology sector. Please let us know what you think and/or what you would like to see in the future!
Top comments (26)
I'm 17 minutes in and getting really distracted by the fact that the point is getting missed.
I've been building a microfrontend for almost a year, and there are good points made around app-size/company size, etc.
But the REAL benefits are avoiding framework lock-in and stability. If I build a microfrontend component (spec compliant web component) and package it up into an npm package, that component lives forever.
I don't have to go back and modify it every time a new version of the framework comes out.
In addition, think of it from the perspective of going framework-less, not in terms of the frameworks (as the microfrontend site example is pretty tortured). The whole POINT of these frameworks, going back a decade, was to allow us to separate concerns and componentize (work in the average jQuery app circa 2008 and you'll know what I mean haha). This isn't about using all the frameworks, this is about not needing them anymore.
If everything is a purely contained component that can run on its own completely independently, then you have a design system, not an application.
If you then compose a set of components into a larger "frame" component, and that frame has an API that it calls on the backend to where each microfrontend is a vertical slice of the application, then it becomes ridiculously trivial to make changes.
You CAN do that with a good component model. Now, change the framework version in an app without a microfrontend.
Example from the real world: Spend five years writing an Angular 1.X site with a bunch of element directives. Now you've finally convinced leadership we need to be using v6 or whatever it's gotten to now. That's a giant project, and one that keeps going every 6 months unless you're ok with eventually being on outdated, unsupported versions of the framework. With a microfrontend you just refactor a piece at a time, not the whole thing.
The Angular 1 to 2 split was the most dramatic, but all frameworks introduce breaking changes at some point that prevent upgrades.
With a microfrontend, if every component is on v1, and the new component is on v2 you can lazily update all other components as time allows without a giant refactor or greenfielding it from scratch (while potentially having a larger download size for a time)
The different teams and different framework examples of the microfrontend site get in the way I think. The real point should be the ability to get away from using frameworks for everything (so obviously Dan isn't going to like it... Not in a conspiracy sort of way, but in a "React is the only answer" sort of mindset), the flexibility to use them if you actually NEED them, and the ability to have disparate pieces coexist on a page in spite of the fact that the developer in 2019 didn't care (or know) what the developer in 2025 was going to do.
Also, just like on the backend, where in theory you could have Go, Node, Python and Java services, you could do the same on the frontend with the big three. Unless it's a google-sized shop, there will probably be pressure if not outright instructions to stick to a stack front and back in most cases.
Ok, time to finish the video... Only 17 minutes in and I wrote a novel... Sorry Lucas. Watch, you'll make all these points 5 minutes from now and I'll look like a dummy haha!
Obligatory perspective: I've been using Stenciljs to compile my components... Maybe that's coloring my view of the ease/difficulty of building a microfrontend
I dont get it, isnt it obvious why this is a bad idea? If you need to have v1 and v2 loaded at the same time in your webpage, your webpage just became x2 more bloated. Doesnt that instantly disqualify the idea of microfrontends? Pretty sure it does. Oh sure, if you just want components to sit on github then by all means, call them whatever you want. But surely the entire point is to use any component you like on the same webapp/page. Then it becomes much more bloated.
It's a tradeoff, but
looks at it as-if that moment in time is the end-state.
MFE's don't advocate for the end-state to be multiple components all running different versions of the same framework. They add the capability, and I think this is where some of the confusion and fear of the concept comes from.
There's also the assumption of bloat. That assumption comes from a decade of top-heavy frameworks that download everything plus two kitchen sinks just to get to "Hello World". Keep in mind that the dream (mine at least) is that we don't need a framework, because the spec and browsers have caught-up. I can componentize and separate concerns inside of a FE app right now in Vanilla JS.
Angular, React and Vue are no longer necessary, but they provide a lot of convenience features and opinionated approaches that help larger teams to standardize their systems.
As I said in an earlier comment, imagine a world where the framework only gets used in the places it's necessary.
Just like technology can't be a solution for organizational issues (and I don't think that's a good application of MFEs either), you can't depend on technology to provide technical leadership and standards. The video's point about Guilds (from the Spotify model) is dead-on. You have to have a person or group from the teams whose job is technical cohesion. So if group "A" says "We need to ramp version on the standard framework to X" and group "D" and "T" pipe up with "We use the standard framework as well", then those teams need to build an upgrade plan to all be on the same version to minimize bloat, but teams "B", "C" and "E-S" don't need to be involved, and the three teams can develop a plan together. For a few weeks or even months there may be two different frameworks downloaded to users.
This is where things outside MFEs come into play. Does your performance budget allow for the slowdown caused by the two framework versions? Is there tree-shaking that could smooth the issue? Is the performance impact noticeable on fast connections? On slow connections? Are we using the smallest possible file-size that the framework allows? These are good practices the team should be performing anyway, and can inform whether or not the teams need to coordinate releases to avoid the version split or if they can upgrade independently.
But the end-state of the application is that there is one version of the framework downloaded to the user's browser. Right now that's the only option available to us. MFE's allow us a new capability to handle upgrade cycles at a smaller, more manageable scale, and could even be considered a new paradigm away from framework monoliths that most developers have gotten comfortable with over the last decade.
Remember how developers recoiled in terror at the thought of SPAs (Bloat, there's no way you can download ALL of the JS for every page, it'll be too big)? JSX (HTML generated from JS. It's dangerous and insecure, and it's flipping the stability pyramid on its head!)? TypeScript (JavaScript is duck-typed by design, this is just trying to make JS into Java-lite)?
I think this reaction to MFEs seems similar, because they do fly in the face of "how we've always done it (for the last 10 years)" and still might be proven to be a bad idea in the long run. But instantly disqualifying it because of the new capability it provides (and fears of how it might be misused) could block a legitimate path to simplifying day to day development.
Hey, thanks for giving your perspective! Although we definitely have disagreements I'm really glad that we can discuss this issue, and I'd love to understand your side better.
I think that this definitely could be true, but I also see there being implicit feature dependencies that arise as a result of business decisions. Very seldom can I design a component that I can just package up to live forever and work forever, either in terms of its dependencies or in its business context. For example, even if my component comes bundled with Angular x.x.x, it's almost certain I will have to update it at some point to meet updated business requirements, and at that point I see maintaining two versions of Angular as technical debt as opposed to a benefit.
I definitely address this in the video. My point is that using too many technologies may and most likely will cause unnecessary maintenance and tech debt issues to arise in the long term.
Thanks for the kind (and thoughtful) reply :D
The first thing I will say is: Imagine if that component didn't have Angular, or React or Vue or jQuery (haha). That's the dream. No external dependencies, just a vanilla web component that meets the spec and therefore will be supported for years to come. Then we write once, install anywhere that we need it (Which is, again, a design system, not an application... think bootstrap/ionic v4/carbon/Material design, only implemented as web components... which Ionic already did).
If I compose my micro-frontend from those components (Into a bigger component) then I don't even HAVE a framework to download to the user's browser.
That said, let's say there is a need for a framework inside of that larger, composed component, or even one of the design-system components. That need is specific to that component, and doesn't impact the other components making up the app. So now the upgrade cycle is contained in this smaller piece.
I think Angular and Vue already provide an optimized (IE: Smaller) versions of their frameworks for use inside of a component, and React is already tiny (but I think they may have or are working on a component solution as well). This simply allows us to use the framework when we NEED it, instead of a default requirement. Getting away from the forced requirement is why it's intriguing, not building with multiple frameworks.
If a business requirement forces me to upgrade the framework, that's GREAT! Now I update this one portion of my application, and as long as I keep the previous data contract with the rest of the application, I can rest assured that there are no side-effects from the change.
For the second quote... I'm not sure you got my intention (which is my fault from a clarity perspective!) I'm making the same point. You CAN do this on the backend with micro-services (Sidenote: You make valid points in the video that micro-services have a certain hype behind them, and monoliths are NOT automatically bad, I just want to note that I appreciate and agree with that sentiment and I think it applies to micro-frontends as well).
BUT:
I'm not saying you should. In fact I recently made a comment on this very issue where I specifically said you CAN, but you shouldn't haha:
dev.to/scott_yeatts/comment/bje6
Stack/technology cohesion is an organizational/leadership issue. If I interviewed with a shop that told me they had Go, Node, Python and Java in the backend I'd give them the side-eye. Same if they told me they had React, Vue AND Angular in the frontend, micro-frontend or not. The point of that comment is that unless you're Google, choosing a technology and not letting developers do whatever they want is important. If you then have a standard (Use framework X where it's needed), a version (We use version x.x.x of the standard framework) and track upgrade cycles (component X needed version x.x.y for a specific reason, we need to start upgrading component y and z so we're not dependent on version x.x.x anymore), then micro-frontends are an excellent tool for creating a separation of concerns similar to that of micro-services on the backend.
Final thought (sorry for the novels, I just get interested in these discussions, especially when they aren't flame-wars, which is why I love this site :D). Micro-frontends DO take longer to build initially, just like micro-services. The benefit shows up later, in maintenance, similar to how unit tests don't make you go faster NOW, but they speed you up six months later when you don't realize you just broke something. Micro-frontends isolate your changes from unintended consequences. If time to market is your primary concern, build a monolith on the backend and a traditional framework SPA on the frontend. If the flexibility of your completed application is primary, micro-frontends might be the way to go. Right tool for the job and all.
Final, FINAL thought: Loved the video. It felt a little like a reaction video (reading the material as you go) vs a breakdown of the concept after an implementation and investment in the concept (which a lot of the authors you looked at seemed to have done).
That initial reaction is SUPER important to the community, because if I THINK an idea is great and I invest a lot of time proving it's great, then I'm not presenting an honest assessment. I want (even NEED) to be right. The best way to avoid a cargo cult is to have people look at ideas with fresh eyes and honestly assess the ideas behind it. So thanks for looking at it!
I think that isolating changes from unintended consequences is incredibly important, so I think we definitely agree on principle.
In terms of practice, I'm willing to say that there are different tools for different jobs. I'm also willing to grant that micro frontends could potentially be one of these tools; however, I do have reservations about their potential misuse and/or abuse, and also the other alternatives that may exist for any given solution.
Thank you for taking the time to watch my video, and I appreciate the dialogue!
No, thank you! You didn't have to engage with the discussion and you did!
I think it IS a case of different tools for different jobs, and I don't think micro-frontends should be used in every project.
I also think they can be misused and hamper development (I've had that experience... I built my components like a design system at first and that mistake caused the build process to be sub-optimal).
Getting an honest reaction to the concept and an honest assessment of the problems involved is what will push the engineering community to avoid hype-driven development. Your podcast and others like it are vitally important to the community. Thank you for doing it (I'd never have the guts to do what you're doing haha!)
I had a similar experience based on what Scott described.
On my first job, which lasted for 7-8 months, I migrate 4 portals written in flask and Jinja built on top of OpenErp to AngularJS.
On one another project,I initially developed a video Q&A based social networking site in AngularJS, migrated it to AppShell architecture, which served SSR ejs templates from express server, we used jQuery intensively for all the interactions and single page look and feel.
Performance was mind blowing and learning experience was tremendous for me.
On my fourth job, Spent 3 years writing spa in angular1.x, decided to migrate to reactjs, however neither the management nor the time provided a luxury of creating a parallel team to migrate the whole product into reactjs or any modern spa framework.
I have described my journey of breaking down the monolithic spa into service oriented frontend here.
This approach has helped us significantly to iron some of the issues, such as develop, release and deploy each product vertical independently.
After implementation of this model,I have seen tremendous improvement in developing and delivering new applications in minimal cost and shortest time to market.
This approach has also made our front-end architecture agnostic to low level implementation details like UI library or framework such as react vs vue or if something better comes in the future.
Do you have real example? Because this tale about migration from AngularJS to Angular sounds weird.
I have to agree with Dan. The whole idea of a framework is to give you a base so you can stick to it. You don't need multiple foundations to build a house
I think we're mostly on the same page here! However, I would say that micro frontends raise some great philosophical and ideological questions about the way we write code and approach programming, and there's definitely merit to both sides in this issue.
I don't understand what they are still. Are micro-frontends just multiple frontends for the same backend? If so, what's micro about that? I feel like I'm missing something.
I think that it's best to first understand the concept of microservices. Microservices are essentially independent "mini-backends" that contain functionality for a particular domain or function. Micro frontends are the same thing, except with frontend code.
The idea is that multiple micro frontends can communicate with each other and work well together, without needing to co-depend too much. There are many additional pros and cons that I cover in my video above. :)
I believe you missed the point of microservices in the first place. They are in most cases isolated programs trying to solve domain specific problems. Typically they run on the same backend framework. So a microservice-based application runs on the very same Java or .Net version. In a containerised deployment they can even use exactly the same container image. The result is unification, shared resources and integration.
The "micro-frontend" is exactly the opposite.
I suppose that was my point.
This makes absolutely no sense.
Think of having multiple different states and problems synchronizing them. Think of CSRF tokens, think of CORS and associated maintenance hell. Think of multiple cookies. Think of authentication and authorization. Think of having downloaded multiple identical or different frameworks, all the duplicated string objects, translations loaded into memory just wasting it. Think of synchronized loading of complex screen with tens of components and making sure everything is up to date and represents ground truth. Unless I ever see a working PoC that does not bring my system to a halt and will not present more problems than SPA I'm not a fan at all...
But what are they? How are they not simply multiple frontends for the same backend? Do the frontends communicate with each other? How and why?
Videos are great, but I prefer reading.
Apologies that the video doesn't do a good job of laying the context and explaining what it is. Here is a (hopefully) clearer explanation.
Firstly lets assume things at scale.
Multiple frontends are a bunch of seperate apps talking to one or many API's, each can come from one or many backends. (This seems to be the norm right now)
Example:
I picked the above example to show that Backends are not 1:1 to api's and apis are not 1:1 to frontends. they are all many to many relationships. This doesn't change whether using micro-frontends or not.
A micro frontend, is a single (just one of those) app cut up in ways such that it will be composed of multiple smaller self contained parts. Example: For
browse and stream, It's one website. You don't want the page to refresh between browsing and streaming. Maybe you can stream as you browse (like youtube). So you cut it up code wise asbrowseandstream. But the UI/UX is the exact same, the user (ideally) should not be able to tell its 2 seperate apps.Right now you have all the functionality in one repo and most likely sharing the same frame work. Micro-frontend is playing with the suggestion that you can completely seperate certain bits. Such that the ONLY assumption is they communicate via a contact (they have to co-ordinate with each other somehow)
So the most basic implementation is just have browse and stream sit on 2 seperate sub-domains. and drop 2 iframes into one page. Then the communication is via
window.postmessageandwindow.onmessage. So when you click on something inbrowseit will pretty much broadcast to thestreamapp that it's clicked on a song and stream just handles that message. There are ofcourse more elegant ways by what was briefly discussed in the video as theFrame.What this does is basically split the app into multiple projects. You can start to build smaller teams that are solely responsible for smaller parts. You can use different technology or CI processes to build each one. You can even put them on different repositories one on svn one on git. Can be hosted on different stacks. The long-winded discussion about tradeoffs and benefits is in the video ;)
Would also like to add the relationship between this and Web Components is... Currently a React.Component is a React component with the
contractdefined by React (props). Web component is supposed to be generic, and fully encapsulated. So we need to think of ways for Components of different technologies and even different versions of the same tech to generically communicate.Why would you iframe 2 components from 2 separate frontends into a 3rd SPA frontend instead of just using 2 components in your SPA
In the video we go in depth about this... There are reasons but I think the host and I both feel the true benefits are harnessed in very niche cases and a good Components model can provide most if not all the benefits at this point in time.
As for the 2 iframe thing. Spotify is actually done like that, so it is currently being successfully used in a large scale production app that most people would say is a leader in the industry. It's also worth noting that some of the problems it solves is not technical but organisational. So even though from a computer science perspective it may seem a bit silly, but from certain organisation/management perspectives it might actually make alot of sense.
Cool. Please describe where I can see Spotify doing this
If you are still interested in learning about service oriented architecture for frontend I have written a post on this topic here
What is micro about having multiple frameworks in one page?
I am sorry, but this is a organizational issue hiding behind “framework locking” and other phrases.
You are investing in more technology....
The user is downloading more things....
The techniques and lessons learned are less shared...
And you claim you can make it all work with web components, which has there own massive set of issue....
This is a solution developed by enterprises that can’t get there shit together. This is a technical problem masking a organizational one.
There is no such thing as framework lock-in that you need micro frontend to solve. You can just solve it.
This usually comes about because you have a structure that has dozens of teams owning incredibly small pieces of a site. Typically the company is hiring java devs and asking them to write the front end in this case...
You can’t make the argument this is ok, just because we can use web components. Web components are for sure not ready for prime time for a amazing long list of reasons. Does the browsers have some level of support, yep. Is it a good developer experience, nope. Does it force more things into Javascript making the bundles worse, yep....
As a organization, just learn how to craft a good front end. Actually hire front end engineers. Build solid components and work on communication. Don’t claim because you use three frameworks you don’t have framework login. You just have disagreement and disorganization.
I think micro-frameworks are just an excuse for Front-End Developers to ease their boredom. The whole idea of "microservices in the browser" sounds silly as microservices are supposed to be independent applications that communicate with each other .
I think a better name would be "A glorified feature flag framework" as the only real reason to use it is to reduce risk when migrating from and old application to a newer one.
This is the most interesting thing I learned about over the 4th of July weekend. The article linked at the beginning also links to many other useful resources!