• 4 min read

Choosing a Micro Frontend Framework

Micro frontends are an effective tool to design and leverage broadly scaling architecture with relative ease. As with any big-picture decision, there are a vast amount of smaller choices to be made to ensure the setup remains strong for years to come.

In one of my recent projects, I decided to take on this challenge, attempting a first-time build on a micro frontend stack. After planning and determining requirements, the earliest major decision was to choose a micro frontend library. Thankfully the stakes are low; this is a simple side project of my own design.

Evaluated Packages

Below are the libraries I examined and what stood out to me about each. They are divided by how the tool composes the UI. Stay to the end to find out which one I chose!

Client Side

  • Luigi - Polished and well thought through website, which I’d hope to see on a product calling itself “The Enterprise-Ready Micro Frontend Framework”. The documentation is easy to read, covering a vast array of topics from navigation and authorization to internationalization (i18n). It includes migration guides from previous versions and a self-aware FAQ mentioning popular alternatives. Many examples cover the current most trendy frontend libraries.
  • single-spa - Some of the most thorough documentation I’ve seen for client-side micro frontend tools. Shallow enough to get rolling quickly, but deep enough to avoid major problems later on. A well thought through, yet opinionated, discussed on techniques available. Smaller scope than Luigi, primarily concerned with orchestration and routing.

Others: FrintJS, qiankun, Berial, and Nuz. I didn’t look too closely at these due to them appearing to be abandoned, have incomplete documentation, or not yet have reached production-ready stability. Of course, the final option would be to build in the micro frontend functionality yourself.

Server Side/Compiled

  • Piral - A fairly extensive set of services for creating render pipelines. Documentation had diagrams scattered throughout that helped put together the whole idea, as well as an introductory video. Nice branding too.
  • Bit - Self-labeled “The Shared Component Cloud”, this appears to be a micro frontends as-a-service. I frequently saw articles promoting Bit and even more articles about general frontend architecture that ended up being sponsored by Bit or written by one of their own employees. It would be difficult to not come across Bit several times after doing research in this area. They seem quite polished, I would be tempted to use them if they fit my use-case.

Others: Project Mosaic, PuzzleJs, and Podium. Some of these packages reach a higher level of complexity than what I’m looking for on my own project. All of them seem like credible contenders.

Both

  • Open Components - Although this one technically supports client-side composition, the registry piece requires more backend services. It also allows server-side rendering, and seems to be well-supported over time. Their documentation setup seemed similar to single-spa in simple complexity and succinct, easy-to-understand documentation.
  • Isomorphic Layout Composer - Similar to Open Components, supports both client-side and server-side rendering. Built by Namecheap. It markets itself to be relatively simple while still addressing large-scale concerns like speed and internationalization. Notably, it builds on the other micro frontend frameworks single-spa and Project Mosaic.

Others: Ara Framework and Mashroom Server. Much like the server-side tools in the previous section, these libraries seem well-rounded and robust enough to handle most use cases. I found these last two slightly more complicated.

The Winner

…and the winner is:

🎉 single-spa 🎉

I chose this one because it appears to be one of the most popularly used micro frontend tools out there. Based on its long track record and the fact that several of the other libraries mentioned in this list are built on top of (or are inspired by) single-spa, I wanted to get to know its setup and broad design decisions.

My goal for this was to lay a foundation of knowledge around tooling and processes that engineers smarter than myself are following. I’m not done yet, but using single-spahas been quite enjoyable so far. It’s a nice mix of opinionated tooling without being too constricting or complex.


A profile photo of Anson Lichtfuss
Written by Anson Lichtfuss, a frontend engineer building useful, beautiful interfaces in Seattle.