Hyvä is on the rise. And not for no reason, it offers an exciting frontend framework for Magento 2 with excellent performance out-of-the-box. One of the reasons that Magento has grown popular is its huge collection of extensions. So it is not strange to ask whether third party modules work with Hyvä or not. If yes, this brings up a vital question whether that compatibility is due to native support or legacy fallback - which to me is a huge difference. Let me bash the legacy fallback.
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.)
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.
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
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
data-mage-init are not mandatory and a simpler inline
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.
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.