How can using a theme that removes all of Magento’s default frontend output and completely replaces it with its own implementation be easier to maintain, you might wonder?

Upgrades

Firstly, let’s consider Magento’s quarterly security/enhancement upgrades, which often include changes to the storefront itself. We’re likely to find far less disruption to a Hyvä based theme than Luma one because of the removal of all the default storefront output Hyvä performs. Due to this, any changes to templates (the files that contain the HTML markup), JavaScript and CSS files in the default Magento codebase in an upgrade won’t impact a Hyvä based theme.

Of course, we have upgrades to the Hyvä Theme itself to consider, but these upgrades can be managed at your own pace and are rarely impacted by the changes to the frontend introduced by Magento’s upgrades.

Components

Hyvä takes a component-based approach, which means each part* of the theme is managed within one file that includes all the markup (HTML), styles (CSS) as well as any dynamic functionality (JavaScript).

*Such as the mini cart, image gallery or any other self-contained aspect of the page

Whereas with a Luma based theme, each of those elements (HTML/CSS/JavaScript) are managed in discrete files with little or no correlation to one another. Using components means it’s easy to upgrade or swap out parts of the storefront without impacting anything elsewhere, reducing the time needed to maintain the theme.

Managing optimisations

As we noted earlier, some optimisations can be made to Luma based themes to improve the performance above the baseline outlined in the speed tests above. The main optimisation that has had the most traction in the past few years is known as JavaScript bundling*.

*Note: this should not be confused will Magento’s inbuilt JavaScript bundling configuration setting that generally decreases the default storefront performance further.

JavaScript bundling involves using an external tool* that combines (or bundles, hence the name) all the default JavaScript files together into just a few files to remove all the individual JavaScript requests on page load and reduce the load time (and increase page speed).

*Such as Magepack or baler.

However, as alluded to above, whilst this improves the speed of a Luma based theme, it still comes nowhere close to the performance Hyvä based themes can offer, especially on mobile devices/connections. Furthermore, introducing a bundling tool adds a further layer of complexity and introduces another layer to the codebase that needs to be maintained.

Sadly, bundling is not a one-time implementation. Every time code changes are made that impact JavaScript in any way (e.g. installing new/upgrading existing modules, adding/modify JavaScript functionality or upgrading Magento), the bundling tool needs to be re-run. Whilst much of this can be automated (with further upfront development investment), any errors picked up during the bundling process need to be managed before deploying code changes.

The point being made here is that the level of effort to keep a Luma based theme even somewhat performant is much greater than a Hyvä one. This, along with the two other points made above, means the same applies to the total cost of ownership (TCO) of a Luma based theme over a Hyvä one.

Why should you care if a developer enjoys working on your site? How does that impact your revenue? Whilst it may not be something a merchant should care about, it is worth taking notice of, as a good developer experience breeds a larger community of developers, which tends to foster greater collaboration and knowledge sharing.

This is to your benefit because a healthy, growing and supportive community means developers supporting your site have access to a group of like-minded individuals to ‘bounce ideas off’ and get help. This generally means solutions to problems that may arise when developing for your site are easier to come by, and the overall quality level of the output increases.

The end result is a more performant/stable site for you! At the time of writing, there are now almost 600 developers/Hyvä enthusiasts on the community Slack channel with frequent discussion and knowledge sharing taking place and many more joining all the time. For a platform that was only announced 6 months ago, that’s pretty impressive!

Hyvä Themes does not require you to start with a fresh (new) install of Magento 2. If you have an existing Magento 2 site, you can simply* replace the current theme and save time, not having to recreate all the backend/admin panel functionality (or external integrations) you may already have in place. If not, starting a new project on Magento 2, whether migrating from Magento 1 (or elsewhere), does not impact your ability to utilise Hyvä Themes.

*It’s a little more involved than that, as we’ll outline in the considerations below, but the key point is that either a new or an existing Magento install is a perfectly suitable place to start implementing your Hyvä Themes project on.

Finally, to ensure absolute clarity, Hyvä Themes is available for Magento 2 only, i.e. Magento 1 is not supported!

Almost every Magento site utilises modules (or extensions) from third-party vendors, whether free or paid. When it comes to using Hyvä Themes, some additional work is often required to ensure the module works functionality and looks good. However, it should be noted this is only in relation to storefront (theme) output, i.e. all backend code, external integrations and admin panel related output are not affected.

As you may have already guessed, what is affected is the storefront JavaScript and CSS output, which will need to be rewritten to support Hyvä Themes way of doing things (i.e. Alpine.js and Tailwind CSS). This may sound like a substantial undertaking, but it depends on the amount of code that needs replacing/converting.

With a Luma based theme, this is less of a problem in that the CSS and JavaScript that ships with a module are supported ‘out tof the box’. However, this is not as clear cut as it might seem, especially from a CSS perspective. From our experience at Fisheye, which I’m sure will be similar for most others, the styles that ship with a module are never usable without at least some level of work to bring them in line with the existing theme used on the site.

At Fisheye, we almost always disregard existing styles and implement our own because building on the existing styles is often more time consuming*. This again supports Hyvä Themes decision to start from a simple, non-bloated base and build/maintain a lean site with minimal complexity and layers of overrides.

*For transparency, we have utilised the popular SASS based theme from Snowdog in almost all of our previous work on Luma based themes at Fisheye, which means using the default CSS (LESS) shipped with modules was never viable in the first place.

Therefore, that essentially leaves us with the problem that any JavaScript written for a third-party module is not useable in a Hyvä based project without being reimplemented. Again the only way to measure this effort is to review the amount of storefront JavaScript included within the modules that we wish to use, which then becomes a consideration between the developer/agency and the merchant regarding whether the additional investment is justified.

It’s worth noting at this point, not all modules even ship with storefront JavaScript, or even CSS, depending on their purpose. We’ve already undertaken an audit of the common third-party modules we utilise at Fisheye to review what we’ll need to reimplement, and whilst some modules will need a decent amount of work to replace the JavaScript, the overall effort is not that great.

In addition, moving back to the plus points of developer experience and availability and the community forming around it, many third-party extensions have already been made compatible with Hyvä Themes. Better yet, these compatibility modules are being shared within the community (i.e. free of charge). At the time of writing, some well-used extensions in the Magento ecosystem have already been made fully/partially compatible, such as Smile’s popular Elasticsuite search and layered navigation solution and Yireo’s versatile Google Tag Manager module.

We haven’t talked about feature coverage to this point, so first, it’s worth noting that Hyvä Themes has recreated almost every piece of storefront functionality in Magento’s Open Source (free) version. Magento Commerce, the paid version of Magento that offers additional functionality, along with their B2B (Business To Business) Suite, have yet to receive much coverage. However, Page Builder (Magento’s Commerce’s advanced CMS offering) and few other items are the only areas to have been recreated.

A list of completed and upcoming features across Open Source and Commerce is visible within the Hyvä Themes feature matrix.

Therefore if you’re building out on Commerce, with or without B2B, you’ll need to outline the areas you want to utilise (again, only on the storefront, backend/admin panel functionality is not affected) to ensure they are recreated as part of your project. Also, whilst Commerce contains a vast number of features, it’s not often a merchant realistically utilises more than a quarter or a third of what’s available.

It is worth noting that some key areas that indirectly impact the storefront are not affected (i.e. work ‘out of the box’), such as content staging & preview and customer segmentation/dynamic blocks.

In addition, many areas with significant presence at the checkout work when using the Luma fallback checkout, such as gift cards, reward points, store credit, custom customer attributes and B2B payment methods (payment on account/credit limits)*.

*These sections only partially work, i.e. at the checkout (for example, you can redeem gift cards at checkout, but the gift card PDP and customer account area section do not yet have support).

So, whilst it is fair to say there is a fair way to go to achieve a decent level of Commerce & B2B support, it is on Hyvä Themes roadmap (again see the feature matrix) and is an important part of the overall offering. At Fisheye, we’re invested in this and are actively working on supporting Commerce functionality, having already built the Page Builder compatibility module (which has been shared with the Hyvä Themes community for use by all).

In all honesty, this section probably warrants an article in itself (and I’ll likely write a follow-up article). Still, I’ll do my best to summarise it as succinctly as possible.

PWAs (short for Progressive Web Apps), or headless sites*, are another relatively new approach to building websites. They also offer fast/performant sites but equally aim to make websites feel more like the apps you use on your phone/tablet, adding features such as push notifications and offline support, amongst many others.

*The terms PWA and headless tend to be used interchangeably, which is not strictly correct, but we’re going to ignore it for the purpose of this article!

PWAs, particularly the offerings in the Magento space (such as Magento’s own PWA Studio and Vue Storefront), are essentially the alternative to Hyvä in a landscape where Luma is no longer good enough.

I can’t answer whether you should opt for a PWA over Hyvä or vice versa in such few words, but where Hyvä’s primary focus is speed and minimal code (incredibly lean sites), PWAs are more focused on providing an app-like experience (one of which is speed) and are often not particularly lean applications. Both can deliver fast sites* and great user experiences, but they require different skillsets and often different budgets and times to market, but this also depends on your requirements.

*At the time of writing, PWA Studio is not matching the speed of Hyvä, with a PDP scoring inline with a Luma on mobile (desktop is much better). Try out this product from the Venia demo (the PWA Studio demo store) on Google Page Speed Insights if you want to see it for yourself.

If you want a fair, unbiased comparison, your best bet as a merchant is to put out an RFI (Request For Information) for both options and see which best meet your needs/budget.