Micro-Frontends: What, Why (and why not) and How

There’s a lot of hype out about how Micro-Frontends are the next big technology trend of 2020. So let’s talk about what Micro-FEs are, why they are interesting, what some of the downsides are, and what the process is to go from a traditional architecture to a Micro-FE architecture.

If you want a video version of this essay check out the associated YouTube video.

What is a Micro-Frontend?

A Micro-Fronted (Micro-FE, or MFE) is the JS, HTML, and CSS required to render just a portion of a single page. That code is in it’s own project and maintained, versioned and deployed separately from the app that’s consuming it. Micro-FEs can be rendered on the server, at the edge or on the client.

We’ve been doing this for a while but the big difference now is in trying to move from one off solutions to a model where all of the Micro-Frontends on a given site conform to a standard. The advantage of this is that it reduces integration costs when working across multiple pages. You can create tooling around that standard, and you can teach to it.

There are three key components to the Micro-Frontend architecture.

  • Micro-FEs — The frontends themselves.
  • Host pages — The routes or web pages where those Micro-FEs will be hosted.
  • Micro-FE framework — The framework used by the host pages to load, unload, setup and render the Micro-FEs on the page.

What are the advantages?

Here are the top four reasons why I’m interested in Micro-FEs.

  • Team Scalability — As you get more people working on a single page the complexity goes up and people start stepping on each others toes. Micro-FEs break up the complexity of the page and enable multiple teams to work on a single page, and to deploy parts of that page independently.
  • Team Specialization — The team working on the host page or on the framework can concentrate on infrastructure concerns, while the teams working on the Micro-FEs can be customer focused. In a single team model the priorities will jump around from sprint to sprint.
  • Reusability — A big win for reusability. If you get the contract between the host page and the MFEs right then you can reuse any MFE on any of your pages.
  • Technology Agnosticism — You can right size the technology to the MFE. A very complex MFE might go with React, while a simpler one might use just Vanilla JS. And the same is true for the host pages. As long as it uses the same MFE Framework then the host page can be written in any frontend framework.

But nothing is without cost, so…

What are the disadvantages?

So there are two big problems with this approach. The first is complexity. The easiest web site to maintain and deploy is a static site that’s just re-built any time a change is made. Second easiest would be a server that’s built, versioned, dockerized, tested and deployed. In those situations the only times you need to really worry are after a deploy since that’s the only time things change. But in the Micro-FE world, with different teams deploying to the same page on different schedules, well, you can have runtime problems. Particularly since Javascript is a single threaded execution model in the browser and there is really no good way to sandbox stuff.

The second big issue is that there is not industry accepted standard for Micro-FEs. A bunch of big name companies have OSS’ed their frameworks; e.g. OpenComponents, Tailor and Zoid. Another popular framework is Single SPA. But there is no “redux” in the Micro-FE world, and IMHO there likely won’t be one because of how the specific needs of each site vary wildly and MFEs are way at the top of the stack.

If you are interested in those frameworks feel free to check out my playlist of Micro-FE videos to get walkthroughs of them.

How To Get Started?

Assuming I haven’t scared you off with the cons let’s talk about some project management level next steps.

  • Step one: Audit — Look at all of the pages on your site and see what components would make good MFE targets. What do you want to reuse? Which ones could use a full team? Gather those up and…
  • Step two: Make requirements — What do those potential MFEs need? Do they need data from microservices? Do they need to talk to the host page, or each other? Do they need to do analytics or performance monitoring?
  • Step three: Build or buy? — Given the requirements you can then narrow down the field of OSS Micro-FE framework options and should they all fail, which is possible, then you have the requirements in hand that you can use to go into the design phase of a DIY Micro-FE framework.
  • Step four: Implement — Once you’ve made the choice then you need to do a phased rollout of pulling code out of the web page projects and building MFE projects with it. Or you need to build the MFE framework and then do that. Dealers choice.


Micro-Frontends are a cool trend and they fit a compelling need for us. Just like Micro-Services enabled much larger backend organizations, Micro-Frontends will enable larger number of web teams. Of course, as with Micro-Services, how reasonable and reliable it will be comes largely down to standards. So get those set up early, be flexible but don’t break, and you’ll probably do just fine.

I YouTube as the Blue Collar Coder on advanced FE topics. Check it out!