How I Used to Build Magento Front Ends (and How I Build Them Now)

The part of a website you actually see, the layout, the colours, the way it sits on your phone, that is the front end. It is the bit that decides whether a visitor trusts you in the first few seconds. Getting it right has always mattered. What has changed is how much of a fight it used to be to get there.

A few years back I ran a small YouTube channel about Magento, and a good chunk of the videos were about the tooling behind the front end. Not the design itself, the machinery that turned my code into the thing on the screen. Looking back, an honest amount of my time went on the machinery rather than the design. Here is how that used to work, and why I do it differently now.

Magento came with a default look called Luma. To build a custom site you did not start from a blank page. You extended Luma, layered your own design on top of it, and spent a lot of effort overriding the bits you did not want. So before a single design decision, you were already working around someone else's theme.

Then there was the build. The styles I wrote were not the styles the browser read. I wrote in Sass, a tidier way of writing the colours and spacing, and a tool called Gulp had to compile that into real CSS, squash it down, stitch it together, and drop it where Magento expected to find it. I made a starter theme to take the pain out of setting all that up, and I still had to keep it running. When Node, the engine underneath, got an update, my whole toolchain broke, and I made a follow-up video just on upgrading Gulp from version three to four so it would run again. That is time spent keeping the tools alive, not building anyone's site.

Later I moved the same job onto Laravel Mix and Webpack, partly to make modules and themes share styles, mostly because the existing setup was fiddly. The pattern never really changed though. Make a change, wait for it to compile, push it to Magento's static files, clear the cache, and only then see it on screen. When the cache did not clear, the change just would not show, and you would sit there wondering what you had broken when the answer was nothing. A fair bit of the day went on fighting the build to see work you had already done.

None of that was wasted, exactly. It is how good Magento front ends got built for years, and I got fast at it. But step back and the real problem is plain. The design was always bending to fit the theme and the tools, rather than the tools bending to fit the design. The starting point was a heavy default look, and a lot of the work was undoing it. Even at my quickest, the site was carrying weight it did not need, and the design had to make peace with what the platform allowed.

These days I do not start from a theme at all. I build the front end out of small pieces, components, using Nuxt and Tailwind. A component is just a self-contained part of the page, a header, a price list, a booking form, that I build once and reuse. Tailwind is how I style those pieces directly, without a separate compile-and-cross-your-fingers step in the middle. Nuxt assembles them into the finished site.

The practical difference is that there is no default look to fight. The page starts empty and becomes exactly what the design calls for. If your brand wants a particular feel, the build follows it. The design leads and the tools follow, which is the right way round and the opposite of how it used to be.

It is faster to build, because I am not undoing a theme before I start, and changes show up as I make them instead of after a cache clear. And it is faster to load, because the visitor only downloads the pieces your page actually uses, not a pile of platform baggage they will never see. The hybrid Magento and Vue setup I built in my last video was an early run at exactly this idea, bolting a light modern front end onto a heavy platform. What I do now just starts light, with nothing to bolt onto.

The honest summary is that building a front end used to mean managing a toolchain, and now it mostly means building the thing you actually want. Less time keeping Gulp and Node and the cache happy, more time on how the site looks and feels and how quickly it loads.

For a business owner that turns into two things you can see. Your site looks the way you want it to, because the build bends to the design instead of the design squeezing into a theme. And it loads fast, because there is far less for a visitor to download, which keeps more of them on the page and gives Google one less reason to bury you. As a rough marker of how far the lean approach reaches, a headless rebuild I worked on for Duffy's Creations scored a perfect 100 on Google PageSpeed. That is the kind of result that is hard to reach when the design is fighting the front end the whole way.

Originally published as a series of videos between 2021 and 2023, rewritten here.