Microfrontends: The good, the bad, and the Ugly by KBall

Last week front-end developers took to Twitter to discuss the topic of microfronds, and both sides had heated debates and opinions.

The “CSS in JS” debate

I think just like CSS in JS, the actual trade-offs and differences depend on the limitations of your project and code organization. There are good ways and bad ways to implement microfronts, so let’s take a look at good, bad, and extremely bad microfronts.

First of all, what is a micro front end

“Micro front-end architecture” is to build a front-end application architecture based on micro services.

The idea is to slice the front-end application into a series of loosely coupled applications that can be deployed separately, and then assemble these applications to create a single user-facing application.

Implementations of microfronts vary from company to company, from server-side page embedding to iframes to Javascript meta-frameworks and Web Components. I recommend this chapter if you want to thoroughly understand the advantages and different approaches to microfrontend.

Advantages: Flexibility and consistency of code organization

Similar to microservices, proponents of a microfront end emphasize the benefits of code organization that reduce cross-team dependencies. Some of the advantages of microservices include:

  • Separate services are deployed separately
  • The team iterates and updates themselves
  • Organize teams individually around business units and products

These are real benefits, especially for large and complex projects, but small applications can also benefit from independent distribution.

Back in 2010, WHEN I was developing an e-commerce site, I was worried about breaking the entire code due to some unrelated change. We built an extensive testing framework to make sure this didn’t happen, which in retrospect was a perfect application scenario for isolating services and microfrontend.

Three. Disadvantages: complex operation

As we move from editing static files to complex build systems, transpilation, and large frameworks, the complexity of getting a well-functioning front-end environment has increased dramatically. Further exacerbating this trend is the microfront end, which may now require multiple coordinated front ends for any kind of testing across the entire application, let alone what tools to use to blend them together.

Challenges that microfront-end veterans may encounter:

  • Many different applications need to be run during development to test the finished experience
  • Tracking and debugging problems needs to span the entire system
  • Versioning across systems

Essentially, you trade front-end simplicity for overall system (front-end/back-end) complexity.

Pain points: performance, inconsistent experience

There is a lot of teasing about the micro front end on Twitter

  • Each team has its own choice, and browsers can end up downloading multiple frameworks and duplicate code
  • Users don’t experience your company website or product alone. This is also one of the arguments against full scoping of components — a problem that can be even worse for a completely separate team.
  • Some implementations of the microfront end, particularly those embedded with iframe, can present significant accessibility challenges

While advocates will argue that these things don’t have to happen, this situation does seem to make it more likely that we will see them.

Compromise: scope of use of micro front end

The pros and cons depend on you and your environment. For small, co-located teams and relatively simple products, the benefits of a microfront end are small relative to the disadvantages, while for large multi-faceted products and multiple distributed teams, the benefits may outweigh the challenges.

There are many ways to gain many benefits without eliminating the adverse effects

By sticking to a single framework and taking advantage of coordination frameworks such as single-spa.js, you can mitigate a lot of the performance penalty by sharing resources and downloading common code only once.

Using shared component libraries also eliminates many of the problems of inconsistent user experiences.

Of course, some independence is given up at each step. At some point, it’s not a microfront-end architecture at all. The exact point within this range that makes sense to you depends on your product and code organization.

In the end, engineering is the art of tradeoffs, and microframeworks give you a dimension to weigh.

This article was published on 2019-06-17.