Is microfrontend the future?

Photo by Edward Howell on Unsplash

Yes, I firmly believe that microfrontend is a game-changer in Web development. Microfrontend enables the independence of development and deployment of Web apps while maintaining a fast, cohesive user experience.

Problem with today’s architecture

Accordingly, Teams are organized to manage the two apps separately.

The reason for this architecture is to reduce dependency. By dividing the large site into two sub-apps, teams can manage their own development and deployment. Less dependency means more autonomy and faster movement.

However, this approach has downsides. The biggest problem is performance. When navigating from one page to the other, even though they seem two tabs next to each other on a page, it takes a full-page reload. The first app is unloaded and removed and the second app is downloaded, resulting in extra costs, including making another SSL handshake, requesting redundant server requests (e.g. user auth), and downloading the same code (e.g. react). And if the user switches back to the previous tab, it takes another wait to download the first app. This is a bad experience compared to single page application, which does client-side routing without full page reload.

Another problem is component reuse. Imagine there is a common UI widget between the home app and the marketing app. Reusing a component avoids duplicated engineering efforts and keeps UI consistent. To reuse a component, a typical approach is to publish the component as an npm package and npm install the component in each app. This, however, creates a dependency: it requires a redeployment of both the checkout app and marketing app at approximately the same time to avoid inconsistent user experience.

And who should be responsible for developing and maintaining a shared component? Since teams are organized on an app level, the ownership of a component is not immediately clear.

How microfrontend can help

Essentially, microfrontend allows the parent app to have access to module code in run time, as opposed to in build time. Conceptually, it’s like

Since the component code is imported in run time, a new version of the component is reflected immediately without the need for app redeployment.

In the world of microfrontend, everything except for the parent app is a component. Components can be pages, pure UI components, and API-connected components. The parent app is a skeleton that manages the mapping between routes and components. Navigating pages is simply mounting and unmounting module components.

With microfrontend, teams are naturally organized by components. A team manages a set of feature-defined components. The success of a team is evaluated not only by their app (page component) performance but also how they contribute to the broader success with their shared components. This finer-grained division better defines team boundaries, encourages cross-team collaboration, tracks team responsibility, and assesses the team’s success.


Emerging technology such as module federation makes microfrontend easier to implement, but it is exclusive to Webpack5 and demands a learning curve.

Get Started


Web engineer @robinhood; PhD in Human-Computer Interaction