Coming up: 27 Oct - Magento 2 Frontend Development: Luma Essentials training

Yireo - Developer training

Open main menu

16 July 2019

Microfrontends for Magento 2

We can agree that the current Magento 2 frontend is hugely complex and outdated. We can also agree upon that PWA and headless in general is the future. But where to start with this migration? This is where I always come in with my term Hybrid PWA.

Hybrid PWA: Adding PWA-elements to the current frontend

The concept is simple: Instead of going all the way with PWA, you can simply add a couple of PWA-like features to the current Magento shop. You can add a service worker, push notifications, a manifest file.

But you can also add Vue and/or React components in the current Knockout/Require system so that you can gradually replace Knockout UiComponents with modern JavaScript components, until you can make the final switch to a complete SPA (Single Page Application).

The concept of microfrontends

What I call Hybrid PWA is in essence part of another broader topic microfrontends, which relates a bit to microservices, but now within the very same frontend application.

The usage of React, Vue and Knockout on a single page might sound sickening, but the concept is not new. Frequently, complex web applications are broken up into smaller pieces, managed by different teams and then each team chooses a specific approach that fits their subproject best: In some cases, web components might suffice, for others React might be a better choice and yet another segment of the page could use Vue. Each team will deal with its own concerns and its architectural decisions.


In e-commerce, this kind of makes sense as well: A product search is a completely different project than the cart functionality (including the checkout).

I can hear you say already that this approach leads to additional overhead because multiple libraries (React, Vue) are loaded on the same page doing the same kind of trick. Thus you increase page load for no reason. True, but the concept is cool. Plus the same concept works for multiple React root components or multiple Vue applications as well - without the additional overhead of different libraries. The concept introduces a new way of thinking, while along the line we also need to focus on performance.

Single SPA

One tool to help with microfrontends is single-spa. It does not necessarily play a role with the migration of Magento 2 frontends to PWA. But it is a nice tool to talk about. single-spa acts as a router, determining for each URL which root component should be used. And it doesn't matter if that root component is built in React or Vue.

I don't think single-spa could play a role in the current Magento frontend, which is a Multi Page Application, not a Single Page Application (SPA). The problem that single-spa tries to solve is a different one than we have with Magento. The method of Hybrid PWA that I envision is that we simply add more and more root components to the current Magento frontend until we have enough to switch to an SPA. However, the concept of adding root components to one application space is interesting.

Multiple React components in a single Knockout page

One specific experiment that I'm running myself is to replace specific Magento UiComponents in a default Luma theme with React components: The minicart, the menu and hopefully more components will follow. This already works fine and could be stuff to use in production as well.

The original React code is compiled using Gulp scripts, that are transpile from React/JSX to ES6 to ES5 to AMD code so that AMD sources can be picked up by RequireJS. The stand-alone libraries of React and ReactDOM are offered as separate RequireJS shims, so that no duplication exists. The only trouble that I still have here is that it is kind of hard to include other third-party React components in here as well because you need to compile those manually to AMD code as well.

Webpack has no place here, because it bundles files rigorously, while we actually want to have separate AMD-compatible sources (that could then be picked up by a RequireJS bundler instead). However, if you only have a single React root component on the page, you can use Webpack just fine.

Replacing just the checkout

One such a scenario where you only use a single React component on the page is the checkout. The regular frontend is still used for the regular pages, but things change in the checkout: Instead of trying to make sense of the overly complex checkout (XML layout spaghetti, display areas, layout processors, KO providers, mixins, to name the essentials), you could just wipe out the complexity and replace it with a straight-forward React components.

The friendly people of integer_net have built such a thing. Part of the work can be found on a GitHub project. And I know of numerous other agencies who have built similar React-checkouts as well. Now that Magento 2.3.2 introduces a checkout based on GraphQL, these solutions could be improved by swapping the old (dead-ugly) REST calls with GraphQL calls.

And development is more efficient because of this. Simply because React development is easier than development in the current Magento 2 frontend. For me, this is again an example of microfrontends but then MPA-style: The regular pages are still using the old frontend, the checkout uses the new one.

Impact on performance

I'm pretty convinced that this microfrontend approach can play a vital role in the near future of Magento. Perhaps, Magento 1 shops can gradually migrate to PWA (using solutions like DEITY and Vue Storefront to ease the pain). With all of this, performance is still important. Loading both Vue and React on a single page is maybe a bad idea.

Loading React or Vue on top of the current Magento 1 frontend (Prototype, Scriptaculous, jQuery) or Magento 2 frontend (Knockout, Require, jQuery) adds another 50-150Kb to an already heavy page. But if the efficiency of development goes up, it might mean that it takes less time to shave off more old components and replace them with modern JS components. Sooner or later, the work pays off.

Posted on 16 July 2019

Looking for a training in-house?

Let's get to it!

Do not miss out on what we say

This will be the most interesting spam you've ever read

We don't write too commercial stuff, we focus on the technology (which we love) and we regularly come up with innovative solutions. Via our newsletter, you can keep yourself up to date on all of this coolness. Subscribing only takes seconds.

Sign up for the Yireo newsletter


GitHub organizations

Legal information

Other Yireo sites

Get Social

About Yireo