Compatibility with Hyvä: Native support

With Hyvä, a new frontend stack is introduced that includes Tailwind and Alpine. More importantly, the old Luma frontend (aka legacy) is removed on purpose - it removes libraries like RequireJS, KnockoutJS, jQuery and more to be replaced with inline Alpine scripts. And because Tailwind is Tailwind (no intro here), you will need to update the HTML-code everywhere to support Tailwind as well. (Yes, there is the @apply trick, but if you care about Tailwind, you should modify the HTML, not the CSS.)

In short, every extension that supports the old Luma frontend needs to rewrite its Luma code to Hyvä code to become native compatible. To ease things, there are ways for an extension to be compatible with both Luma and Hyvä. You can ship Hyvä-only XML layout code. You can write vanilla JavaScript that supports both Knockout and Alpine. You can move PHP logic into ViewModels as much as you can.

Supporting Hyvä natively is key

The main point is still: If an extension is to be supporting Hyvä natively, its code needs to be refactored to only use Tailwind and Alpine and not much more.

Legacy fallback

Adding native support can be a burden. The Hyvä community is hugely active to add native support for numerous third party extensions. Sometimes, this is quite easy with a simple PHTML-rewrite converting LESS-based HTML into Tailwind, adding a few snippets of Alpine only if needed. But sometimes, this is much more work, perhaps even an unreasonable amount of work (which I would question later though).

The legacy fallback system has been created to allow an easy way out. And the best example is the checkout. For instance, if you use the original Luma checkout together with numerous third party extensions, you may want to keep using it with Hyvä so you don't need to convert all of that code into Hyvä. And this is especially true when it comes to the fact that there is no Hyvä checkout based on Alpine / Tailwind. There is a React checkout. There might be a MageWire checkout. But - as of yet - there is no Alpine / Tailwind checkout. It's a tough choice.

Because of this, Hyvä offers the ability to fallback to another theme (say: a Luma-based theme) for a specific URL (say, the checkout). And because of this, a Luma checkout is suddenly usable with Hyvä as well, without requiring anything of that Luma checkout to be converted to Hyvä. Nice?

Is legacy fallback real Hyvä compatibility? No!

Here comes the real point of this blog: Does the usage of the Hyvä legacy fallback mechanism classify a certain third party extension as Hyvä compatible? I would disagree.

Let's say I've built a Knockout-driven newsletter widget for the Luma theme, that shows up on all pages. Next, somebody asks whether it is compatible with Hyvä. If I would say that it will work with Hyvä by enabling legacy fallback for all pages, then I would be technically correct. But letting my extension work by disabling Hyvä for all pages is obviously the opposite of supporting Hyvä.

So why is a checkout being supported by Hyvä by disabling Hyvä on the checkout page any different? Personally, I'm a bit disappointed by saying an extension works with Hyvä this way and then calling it compatibility. Because it is not compatibility at all. In other words, an extension can only support Hyvä for real, if that extension supports the Hyvä stack - nothing more, nothing less.

Even worse, using a checkout like the OnePageCheckout via a legacy theme will cause visitors to load all legacy code at once on the checkout-page (without a useful browser cache). All pages will be extremely fast but the checkout will be dead-slow. I'm not a conversion specialist, but that's normally for me a reason to leave the shop and search for alternative instead. Using the legacy checkout with Hyvä might lower conversion rates (but again, I'm not an expert).

So what to do instead?

The hard message here is one that I've already stated earlier: If you want to have an extension support Hyvä, then your extension needs to convert legacy Luma-code into Alpine/Tailwind-based Hyvä-code instead. And yes, this is hard work.

Creating extensions properly is hard work

But if you haven't done any code conversion of legacy KnockoutJS/RequireJS code towards more modern practices in the last 5 years, then you have been at a stand-still: The Knockout project is not dead but slowly fading away. RequireJS hasn't been a good practice for years. jQuery is laughed at by JavaScript developers. The LESS code written by Magento was ugly and slow-to-compile from the start and it doesn't embrace modern CSS standards. The concept of UiComponents is masochistic. And the whole thing is slow, duh. There's plenty of reasons to improve things, even if it would only apply to your own module.

Modernizing Luma code

So what could you do? Instead of doing a complete code migration, gradually modernizing Luma code is an option. KnockoutJS UiComponents can often be migrated to simpler RequireJS-widgets - the usage x-magento-init and data-mage-init are not mandatory and a simpler inline require() is more performant anyway. With that conversion, custom JavaScript code could / should be separated from Magento-specific code - perhaps in separate files, perhaps in the same file, as long as you know which code works without Magento and which code does not. Converting all code in total to vanilla JS is an even better option. In the end, you will still have a migration to do with Alpine, but the cleaner the code is, the easier it will be to migrate.

Often if someone says it will be a nightmare to convert an extension to be Hyvä compatible, it is because the extension its code is a nightmare to begin with.

Convert your Blocks to ViewModels. And keep them as SOLID as possible. If a ViewModel has 2 tasks, split it up into 2 ViewModels. Have as little dependencies in such a ViewModel as well. Those ViewModels are useable in Hyvä as well. Keep your PHTML templates slim: Templates of 100 lines of code are probably better split up in smaller templates. Use your own CSS identifiers and don't overuse LESS. The cleaner the code is, the easier it is to migrate.

Creating independant code

Clean code is easier to convert to Hyvä. And with Hyvä, there are various ways to have an extension work with both Luma and Hyvä: Different XML layout, different PHTML templates, different CSS and JS, but the same ViewModels and perhaps the same legacy JS-code.

But another totally different approach is to create code that is independent of Luma and Hyvä. The term micro frontends comes to my mind: I've already created various extensions with React components in the Knockout admin panel. You can create your own custom PHP code driving a snippet in the frontend. Or add JavaScript-logic with only vanilla JS. Or go for microservices or SaaS instead. Adding React or Vue on top of Knockout is probably not a good thing, but adding vanilla JS is definitely not bad.

By going for a strategy where your code is no longer tightly coupled to the choosen Magento frontend, you can reduce the work of supporting multiple frontends at once.

The future of Magento

I'm writing this end of 2021, kind of like a Hyvä-flavored Christmas message: Adobe is having a hard time sattisfying the Magento open source community. Different frontends like Hyvä could be proving to be more succesful than Luma legacy and/or Adobe PWA Studio. Everyone knows Luma is dead but because of business-reasons a lot of people seem to be hesitant to say this out loud. Also, because the adoptation of the official alternative - Adobe PWA Studio - is a bit tougher.

Hyvä has caused a stir in the Magento community. But my personal vision is that Tailwind popularity is just a momentary thing, like any frontend movement. The problem (well, sure it is actually a benefit) is that frontend technology is moving fast and an eosystcem like that of Magento is struggling to keep up. I think it would be fair to say that Tailwind (and with that, Hyvä) is sticking around for years to come - just like Prototype and Knockout. But I think it would also be reasonable to state that within a couple of years time, there will be an even better solution and some Magento developers will be smart enough to make Magento adopt that as well.

Change is coming. And Hyvä is just many of those changes as well.

Adopt for changes

Not adopting to Hyvä would be unwise. But I would also say that extension vendors should work harder to support all frontends out there (Luma, Hyvä, Adobe PWA Studio, Vue Storefront 1 + 2, Scandi and many more) in way or another. Not supporting a frontend X in full is reasonable, but not anticipating anything of that frontend is ignoring the fact that tomorrow there will not be a single Magento frontend, there will be many.

And let's not pretend that extensions that work together with Hyvä only because the legacy fallback allows you to remove Hyvä on a specific page, is compatibility. It is just a workaround.