Open the network tab on a stock Magento storefront and count the JavaScript. You'll find jQuery, RequireJS pulling in dozens of small AMD modules, and Knockout.js wiring up the cart and checkout, all before a single product image finishes loading. That's the Luma theme, and it's been the default face of Magento for a decade. It's also the reason so many Magento stores quietly fail Core Web Vitals.
For years the escape hatch cost money. Then, in a short stretch of late 2025, the whole frontend question shifted under everyone's feet. Hyva, the server-rendered theme that had become the community's favorite way off Luma, relicensed itself free and open source. And Adobe, meanwhile, let PWA Studio settle into maintenance while it poured its energy into something else entirely. If you're speccing a Magento build for 2026, the menu you're choosing from is not the menu you knew in 2023.
What actually changed in late 2025
Two things happened, and they point in different directions.
Hyva went free. On November 10, 2025, Hyva announced it was relicensing its Theme under OSL-3.0 and AFL-3.0, the exact dual license Magento Open Source itself uses. In their words: "like Magento Open Source, our Theme can be used free of charge and redistributed under commercial licenses." Before that, the Hyva Theme was a paid license, reported by the community at roughly 1,000 euros (a bit over a thousand dollars) per store. That price tag was the single biggest thing keeping teams on Luma out of inertia. Overnight, it was gone.
Adobe moved on from PWA Studio. Not with a funeral, not with a deprecation notice, just with where the roadmap went. Adobe's frontend attention shifted to Edge Delivery Services, and PWA Studio slid into the same maintenance-mode existence Luma has lived in for years. More on exactly what "maintenance mode" means below, because the internet loves to overstate it.
So the free option got better and the Adobe-official option changed identity. Both of those change the answer to "what do I build my storefront on."
Why Luma was always the problem
To understand why Hyva took off, you have to understand what it's running away from. The classic Luma frontend is built on four technologies that all made sense in 2015 and none of which you'd pick today: Knockout.js for data binding, RequireJS for module loading, jQuery for DOM work, and LESS for styles.
The problem isn't that any one of them is terrible. It's the compound weight. RequireJS fetches a long waterfall of tiny JavaScript modules. Knockout stands up an entire MVVM layer to keep the cart and minicart in sync. jQuery sits underneath all of it. The result is a storefront that ships a large JavaScript bundle and does a lot of work on the main thread before the page is interactive, which is precisely what Largest Contentful Paint and Interaction to Next Paint punish you for. Agency migration write-ups routinely describe a Luma product page pulling well over a megabyte of JavaScript across a couple hundred files. You can tune it, you can lazy-load, but you're fighting the architecture the whole way.
Here's the shape of a typical Luma interaction, wired through Knockout's declarative bindings:
<!-- Luma: Knockout binds the DOM to a view model, RequireJS loads the component -->
<div data-bind="scope: 'minicart'">
<span data-bind="text: getCartParam('summary_count')"></span>
</div>
<script type="text/x-magento-init">
{ "[data-block='minicart']": { "Magento_Ui/js/block-loader": "..." } }
</script>
To make that span update, the browser has loaded RequireJS, resolved the Magento_Ui module graph, instantiated a Knockout view model, and bound it to the DOM. For a number in a corner.
Hyva's bet: ship almost no JavaScript
Hyva made one architectural decision and built everything around it: render on the server, and send the browser almost no JavaScript. It throws out Knockout, RequireJS, jQuery, and LESS entirely, and rebuilds the storefront on just two things: Tailwind CSS for styling and Alpine.js for the small amount of interactivity a page genuinely needs.
Alpine is the key. It's a tiny library that lets you sprinkle behavior directly into markup, no build-time module graph, no view models. That same minicart counter becomes a few attributes on an element:
<!-- Hyva: Alpine holds a little state right in the markup, no module loader -->
<div x-data="{ count: 0 }" @update-cart.window="count = $event.detail.count">
<span x-text="count"></span>
</div>
No RequireJS waterfall, no Knockout instance. The page arrives fully rendered from the server, and Alpine hydrates the handful of interactive bits. The reason Hyva wins on performance isn't a clever trick, it's subtraction: there's simply far less JavaScript to download, parse, and execute. Teams that migrate consistently report their storefronts moving from failing Core Web Vitals to passing them, and the mechanism is exactly what you'd expect from cutting the main-thread work by an order of magnitude.
Now, the honest part about "free," because it's not quite all-you-can-eat. What went open source is the Hyva Theme and its compatibility modules. Hyva Checkout, Hyva Enterprise, and Hyva Commerce stayed commercial, and the UI kit was split out into its own paid product. So a store built on the free Hyva theme is genuinely free; a store that also wants Hyva's dedicated checkout is still writing a check. That's a fair deal, and it's still a categorically different world than "a thousand dollars per store before you render a single page."
PWA Studio didn't die, it stopped being the plan
Let's be precise here, because this is where hot takes go wrong. PWA Studio, Adobe's React-based headless storefront (the magento/pwa-studio repo and its Venia storefront), is not dead, deprecated, or archived. The repo still gets commits. It's still shipping point releases, with v14.5.1 landing in May 2026. There is no official Adobe end-of-life notice, and if you're running it in production it isn't going to stop working.
What happened is subtler and, for planning purposes, more important: it stopped being where Adobe invests. The releases are compatibility and security work, PHP version bumps, dependency updates, the maintenance you do to keep the lights on, not major new capability. The community consensus, which Adobe hasn't contradicted, is that active feature development wound down and the strategic focus moved elsewhere. In other words, PWA Studio now sits roughly where Luma sits: supported, functional, and not the future.
That's the framing that matters when someone pitches you a new PWA Studio build in 2026. It'll work. But you'd be adopting Adobe's yesterday, not its tomorrow.
Adobe's actual 2026 answer: Edge Delivery Services
Adobe's tomorrow is Edge Delivery Services, the same tech behind its AEM sites, now aimed at Commerce. The pitch is a storefront assembled from Commerce drop-in components (prebuilt, customizable pieces like product details and cart) plus content authored as documents, served from Adobe's edge. Adobe markets it as the path to "the fastest storefronts on the web," and there's a real official starting point: the hlxsites/aem-boilerplate-commerce template repo.
It genuinely is fast, because the model is edge-served and light by design. But go in clear-eyed about the tradeoff, because it's a big one. EDS is a fundamentally different way to build. The document-authoring model, the block-based component system, and the AEM lineage mean your team isn't writing a Magento theme anymore, they're learning a new platform with its own mental model and its own gravity. Adobe presents EDS as its strategic direction rather than publishing a literal "this replaces PWA Studio" statement, but the direction of travel is not subtle.
So what do you actually build on in 2026?
Here's the decision, stripped down.
Luma is legacy. Pick it only if you're maintaining an existing store and a re-theme isn't on the table. It works, it's supported, and it will keep quietly costing you Core Web Vitals. Don't start something new here.
Hyva is the pragmatic default now, and going free is what makes that true. It's server-rendered, it ships almost no JavaScript, the performance story is real, and, crucially, it's still just a Magento theme. Your existing Magento developers can work in it, you can hire for it, and you're not betting the store on a new platform paradigm. For the large majority of Adobe Commerce and Magento Open Source builds in 2026, this is the boring, correct answer.
Edge Delivery Services is Adobe's bet on the future and the best raw performance ceiling, but it asks the most. Choose it if you're aligned with Adobe's roadmap, you have a team willing to learn the EDS/AEM model, and top-end speed is a hard business requirement worth a steeper build. It's the strategic pick, with strategic-sized costs.
And if you're a composable shop that wants a fully custom head, the fourth door is still open: build your own frontend (Next.js or Nuxt against Magento's GraphQL API), or use Alokai, the commerce frontend platform that used to be Vue Storefront before its 2024 rebrand. More freedom, more to own.
The through-line is that the cheap, sensible middle finally exists without an asterisk. For years the good answer to "how do I get off Luma" had a thousand-dollar-per-store price attached, and plenty of teams stayed stuck because of it. That barrier is gone. If you're still shipping Knockout and RequireJS to your customers' phones in 2026, the reason can't be budget anymore. It's just habit.
Originally published at andriiboyko.com.
