Hyva theme development is building a Magento 2 or Adobe Commerce storefront on Hyva’s Tailwind CSS and Alpine.js framework instead of Luma’s jQuery, Knockout, and RequireJS stack. It involves scaffolding a child theme through Composer, overriding .phtml templates, compiling Tailwind, wiring Alpine interactivity, and adapting extensions with compatibility modules, usually to reach 90-plus PageSpeed and pass Core Web Vitals.
Search for “Hyva theme development” and you get a wall of near-identical service pages: the same performance claims, the same three-line install snippet, the same menu of services. What almost none of them show is what the work actually feels like day to day, or how the scope really breaks down on a build. This article is the process pillar the commodity pages skip, written by Bemeir, the USA’s first Hyva Gold Partner.
What Hyva theme development actually means
Two things share the name “Hyva,” and conflating them causes most of the confusion online.
The first is the Hyva theme: a frontend framework that replaces Magento’s default Luma theme. This is what people usually mean by Hyva theme development, and it is now free and open source.
The second is the Hyva product suite: a set of commercial add-ons around the free theme, including Hyva Checkout, Hyva UI, Hyva Commerce, and Hyva Enterprise. Per Hyva’s Q1 2026 product recap, the theme is free while Checkout, UI, Commerce, and Enterprise remain paid products. When a page says “Hyva costs X,” it is almost always talking about a suite product, not the theme.
Hyva theme development, the subject of this guide, is the work of turning that free theme into your store’s actual storefront. It sits inside a broader Magento and Adobe Commerce development engagement, because a storefront still needs a platform, integrations, and data behind it.
The tech stack, and what Hyva removes
The reason Hyva is fast is mostly a story of subtraction. A Luma product page commonly ships several hundred kilobytes to over a megabyte of JavaScript across a large module graph. Hyva ships a small fraction of that, because it removes an entire layer of the old frontend.
Out go RequireJS (the module loader), Knockout.js (the data-binding layer), jQuery, and the Magento UI Components system, along with LESS. In come Tailwind CSS and Alpine.js: Tailwind for utility-first styling that compiles down to a tiny purged stylesheet, and Alpine for lightweight reactive behavior written directly in markup. A small amount of plain JavaScript covers the rest.
The practical consequence is that Hyva ships as a blank slate. It does not reuse Luma’s templates, layout JavaScript, or stylesheets. That is a feature, not a gap: nothing legacy loads unless you deliberately bring it back.
Scaffolding a Hyva theme
A real Hyva build starts with environment checks, because Hyva has firmer requirements than Luma. Per the official Hyva getting-started documentation, you need a recent Magento 2.4 patch release, PHP 8.1 through 8.4, and Node.js 20 or higher on any machine that will compile the theme. You also register for a free Hyva Packagist key.
The install path is Composer-based:
- Add the Hyva Packagist credentials and repository.
- Run
composer require hyva-themes/magento2-default-theme. - Run
bin/magento setup:upgrade. - Activate the Hyva theme under Content, Design, Configuration.
- Turn off Magento’s built-in HTML, CSS, and JavaScript minification and bundling, which the docs explicitly recommend because those features fight Hyva’s own optimized output.
From there, real work happens in a child theme, not the default one. You create a theme directory with a registration file and a theme.xml that inherits from hyva/default, bring in the Tailwind configuration, and run the Tailwind compiler in watch mode so styles rebuild as you save. The default theme repository, hyva-themes/magento2-default-theme on GitHub, is the reference for how everything is wired.
The day-to-day development workflow
This is the part the commodity pages never show. A working Hyva session looks like three things happening together.
Template overrides. You customize the storefront by copying a Hyva .phtml template into your child theme and editing it. There is no Knockout binding to reason about; the template is server-rendered PHP that outputs HTML with Tailwind classes. Hyva’s coding standard asks for a short PHPDoc block at the top of each template declaring the block and view-model types, which keeps large teams sane.
Tailwind compile loop. The Tailwind watcher runs in a terminal, recompiling the stylesheet on every save and purging unused classes so the shipped CSS stays small. You style by writing utility classes in markup rather than editing a separate stylesheet, which is the biggest day-one adjustment for developers coming from LESS.
Alpine for interactivity. Anything that needs to react on the client, a dropdown, a quantity stepper, a tabbed panel, gets an Alpine component written inline with an x-data attribute or loaded as a small script. Where Luma would have you register a RequireJS module and wire a Knockout view model, Hyva has you write a few lines of declarative Alpine next to the element it controls.
For anything genuinely dynamic, such as cart and account data, Hyva reads from Magento’s GraphQL layer while keeping the rest of the page server-rendered for speed.
The extension problem, and why compatibility modules exist
Here is the reality that surprises first-time Hyva teams: many of your existing Magento extensions will not render correctly on Hyva out of the box. Any extension whose storefront output depends on Luma templates, jQuery widgets, RequireJS modules, or Knockout will show broken or inert markup, because Hyva does not load that runtime.
The fix is a compatibility module: a thin adapter that provides Hyva-native .phtml and Alpine equivalents for the extension’s frontend, while leaving its backend PHP logic untouched. Sometimes the vendor ships one. Major extension vendors and Bemeir’s wider network of technology partners increasingly publish Hyva compatibility packages, and Hyva maintains a public tracker of which modules are already covered. When no compatibility module exists for a business-critical extension, someone writes one, and that adaptation work is the single most common driver of migration effort. It is worth auditing your extension list against the tracker before committing to a timeline.
Checkout and dynamic data
Checkout deserves its own note because, again, two different things share a name.
Hyva Checkout is a commercial product in the suite, built on Magewire and Alpine rather than Luma checkout. It is the mainstream choice for Hyva stores that want a fast, supported checkout, and standard payment and shipping extensions generally need their own Hyva Checkout integration modules to work with it.
Hyva React Checkout is a separate, free, open-source project: a React application that talks to Magento over GraphQL. It is a toolbox rather than a drop-in product and expects a React developer. Teams reach for it when they want a headless checkout and have the front-end engineering to support it.
Choosing between them is a real architectural decision, and it should be made early, because it shapes which payment integrations you need and how much JavaScript your checkout ships.
Greenfield build versus Luma migration
Hyva theme development comes in two shapes, and they scope very differently.
| Dimension | Greenfield build | Luma to Hyva migration |
|---|---|---|
| Starting point | New store, no legacy templates | Existing Luma store with customizations |
| Main constraint | Volume of design and components to build | Number of custom modules and depth of Luma theme customization |
| Extension work | Check compatibility as you add extensions | Audit every existing extension, buy or build compat modules |
| Custom JavaScript | Written natively in Alpine from the start | Re-implemented from Knockout and jQuery into Alpine |
| Risk profile | Design and content heavy | Regression heavy, needs strong QA against the old store |
The honest summary is that migration cost and timeline are driven far more by your custom-module count and how heavily your current Luma theme was customized than by any per-page rate. Published cost and timeline figures for Hyva builds vary widely by source and store complexity, so treat any single number you see online with suspicion and ask a partner for ranges from comparable builds instead. For a deeper treatment of the migration path specifically, our Hyva versus Luma decision guide covers the tradeoffs in detail.
Performance, and what Hyva does not fix
Hyva reliably improves front-end performance and Core Web Vitals because it ships far less JavaScript and renders the storefront on the server. Stores that were failing Core Web Vitals on Luma frequently pass on Hyva, and the PageSpeed gains are the reason most merchants make the move. Bemeir has seen large PageSpeed improvements and, on one project for the Affordable Screen Company, a roughly 25 percent conversion-rate lift after moving to a modern frontend.
What Hyva does not do is fix your backend. It is a frontend rewrite, so it will not repair slow server response times, an overloaded catalog, weak hosting, or an unindexed database. If your time to first byte is poor, Hyva makes the paint faster but cannot cure the wait for the server. A serious build treats performance as a full-stack question and does not sell Hyva as a cure for backend problems it cannot touch.
What changed in 2026
Hyva moved quickly in late 2025 and 2026, and older articles are now wrong on several points. The core theme went free and open source in November 2025. Hyva added support for Tailwind v4, which shifts configuration from a JavaScript file to CSS and uses a faster Rust-based build engine, and introduced CLI helpers for the new setup. The commercial suite also expanded, with Hyva Commerce and Hyva Enterprise bundling checkout, UI, media optimization, and other capabilities at annual pricing. If you are reading a Hyva tutorial that still lists a per-store theme license fee, it predates these changes.
Where Hyva fits among platforms
Hyva is specifically a Magento and Adobe Commerce frontend. If you are weighing platforms more broadly, a store might instead land on Shopify or Shopify Plus, Shopware, or BigCommerce, each with its own frontend model. What Hyva offers, uniquely, is a way to keep Magento’s depth while getting the front-end speed that usually pulls merchants toward simpler platforms. When the decision is to stay on Magento and get fast, Bemeir’s Hyva development is the work of getting there.
Frequently asked questions
Is Hyva free?
The core Hyva theme is free and open source (OSL-3.0 and AFL-3.0) as of November 2025. Hyva Checkout, Hyva UI, Hyva Commerce, and Hyva Enterprise remain commercial products. So Hyva theme development itself carries no license fee, but specific suite add-ons do.
Do my existing Magento extensions work with Hyva?
Only if the extension ships Hyva templates or a compatibility module. Any extension whose storefront relies on Luma markup, jQuery, RequireJS, or Knockout must be adapted with a compatibility module before it renders correctly. Audit your extension list against Hyva’s public compatibility tracker early.
How long does a Hyva build or migration take?
It depends far more on custom-module count and customization depth than on store size alone. Published ranges run from a few weeks for simple stores to several months for complex ones, and they vary widely by source. Ask a partner for timelines from comparable builds rather than trusting a generic figure.
Do I need to know React to develop a Hyva theme?
No. The theme itself is Tailwind, Alpine, and server-rendered .phtml, no React required. You only need React if you choose Hyva React Checkout, the separate free GraphQL checkout project, which is deliberately a developer toolbox.
Will Hyva pass Core Web Vitals?
It strongly helps, because Hyva ships far less JavaScript and renders on the server, and many stores that failed on Luma pass on Hyva. But Hyva is a frontend rewrite. It will not fix slow server response times, backend catalog performance, or hosting, so treat performance as a full-stack effort.
