Most Shopify stores still run on Liquid. That's true today, and it will stay true for a while. It's fast out of the box, cheap to run, and there's nothing extra to host.
Hydrogen is different. It's Shopify's own React framework, built for stores that need more control over the frontend than Liquid can give.
This post walks through both. No sales pitch, just the real trade-offs, some code, and an honest answer to the question people keep asking: when is it actually worth going headless?
What Liquid Gets Right (and Where It Runs Out)
Liquid is Shopify's own template language. Tobias Lütke, one of Shopify's founders, built it, and it's been running real stores since 2006. That's longer than most of us have been writing code for a living.
Liquid is also strict on purpose. Merchants can edit their own theme files, so the language can't do everything a full programming language can do. It has to stay safe, since store owners are the ones typing into it, not developers.
That limit is a good thing, not a flaw. It's why a small business owner can tweak their homepage at 11pm without breaking checkout.
For most stores, Liquid is still the smart choice. It renders right on Shopify's servers. No extra hosting bill. No build step to babysit. No framework update to plan around every few months.
Online Store 2.0 made this even better. JSON templates and drag-and-drop sections gave merchants a lot of the flexibility that used to send people looking for custom builds.
So where does Liquid stop being enough? Usually it's one of these three things:
- The frontend needs to act like an app. Think shared cart state across brands, heavy interactive UI, or checkout flows that need custom logic.
- The brand needs one design system across more than the store. A marketing site, a mobile app, and the storefront all sharing the same components.
- The dev team just knows React better than Liquid, and building in Liquid would slow them down more than it helps anyone.
What "Going Headless" Actually Means
People throw the word "headless" around a lot. Let's slow down and define it properly.
On Shopify, going headless means you split the frontend from the backend. The frontend is what shoppers see and click. The backend holds the product catalog, cart, checkout, and orders. Instead of Liquid rendering pages on Shopify's servers, your own app fetches data through an API and renders it however you want.
That API is called the Storefront API. It's a GraphQL endpoint, and it isn't locked to one framework. You can call it from a plain Node app, from Next.js, or from Shopify's own Hydrogen.
Here's the part most people skip past. Going headless is really three choices bundled into one:
- Which framework you build the frontend in
- Which API you pull your data from
- Where you host the result
These don't have to travel together. Hydrogen can run on hosts other than Shopify's own Oxygen. And Oxygen can host things that have nothing to do with Hydrogen.
Inside Hydrogen: What's New in 2026
Hydrogen has changed shape more times than most frameworks manage to survive.
It launched in 2022. Then Shopify bought the Remix team and rebuilt Hydrogen on top of Remix. Then Remix's routing engine split off into its own project, React Router 7, and Hydrogen moved onto that instead.
Right now, the stable version of Hydrogen runs on React Router v7 and TypeScript. It tracks the Storefront API and Customer Account API on a schedule, and that schedule updates every quarter.
That update schedule is worth planning for. Hydrogen and hydrogen-react are tied to specific versions of these APIs, and since Shopify updates them every three months, breaking changes can show up every three months too. Budget time for that. It's a real, ongoing cost, not a one-time thing you fix and forget.
The bigger news is what comes next. In the middle of 2026, Shopify showed off a rebuilt version of Hydrogen. The old version asked you to adopt the whole framework. The new one is more like a toolkit you bring into whatever stack you already have.
This new preview has a core written in plain JavaScript, with thin adapters that make it feel native to whatever framework your team uses. React support ships first. Vue and Svelte support are on the way.
It also ships with something Shopify calls agent skills. These are structured instructions that let a coding agent set up the Storefront API client, cart, product pages, and checkout hooks for you, in whatever framework you picked. That's a shift from copying boilerplate by hand.
Whatever comes next, the current stable release is what real stores run today, and it holds up well. It uses the open source React Router framework, supports optimistic UI and nested routes, and it deploys for free on Oxygen, Shopify's own hosting network.
Liquid vs. Hydrogen: A Straight Comparison
Neither one wins in every case. Here's how they actually stack up:
| Liquid (Online Store 2.0) | Hydrogen (React Router 7) | |
|---|---|---|
| Hosting | Included, no extra setup | Free on Oxygen, or any Node/edge host |
| Language | Liquid plus JSON templates | TypeScript and React |
| Skills your team needs | Theme development, CSS, a bit of JS | Solid React skills, plus GraphQL |
| Can merchants edit it themselves? | Yes, through the theme editor | Not easily. You'd need to add a CMS layer |
| App compatibility | Wide. Most apps just work | Mixed. Some apps built for Liquid themes need custom wiring |
| Speed out of the box | Fast by default | Fast only if someone tunes it |
| Best fit | Most D2C and B2B stores | Complex catalogs, custom UX, multi-brand builds, AI-driven shopping |
That speed row needs a warning label, because it's the claim people stretch the most. A well-tuned Hydrogen store can absolutely beat a bloated Liquid theme. But "well-tuned" is carrying a lot of weight in that sentence. It means someone who understands edge caching and streaming rendering is actively setting it up, not that Hydrogen wins by default.
Google is pretty clear on this point too. Core Web Vitals are supposed to be measured out in the real world, based on how real users experience a page, and site owners shouldn't have to become performance experts just to know if their site feels fast. That's exactly the bar a rushed, untuned headless build usually misses.
The Same Data Fetch, Two Ways
Let's make this less abstract. Here's the same small task done in Liquid, then in Hydrogen: pull a product's title and price and show them on the page.
In Liquid, the product object is already sitting there, ready to use. No API call needed:
<h1>{{ product.title }}</h1>
<span class="price">{{ product.price | money }}</span>
In Hydrogen, you write a loader that queries the Storefront API's GraphQL endpoint, then you render what comes back:
// routes/products.$handle.jsx
export async function loader({ params, context }) {
const { product } = await context.storefront.query(
`#graphql
query Product($handle: String!) {
product(handle: $handle) {
title
priceRange {
minVariantPrice { amount currencyCode }
}
}
}`,
{ variables: { handle: params.handle } }
);
return { product };
}
export default function ProductPage({ loaderData }) {
const { product } = loaderData;
return (
<>
<h1>{product.title}</h1>
<span className="price">
{product.priceRange.minVariantPrice.amount}{' '}
{product.priceRange.minVariantPrice.currencyCode}
</span>
</>
);
}
Same end result. Very different amount of code to own.
The Liquid version has no build step and nothing to ship to the browser beyond the rendered HTML. The Hydrogen version gives you full control over that markup and lets you mix it with any React component in your app, but you're the one writing and maintaining the query, the loader, and the rendering logic from here on out.
When Headless Actually Pays Off (and When It's Overkill)
Ask yourself these questions before you commit to a headless rebuild.
Does your catalog or user experience need logic Liquid genuinely can't handle? Product configurators, live inventory pulled from several warehouses feeding one custom availability rule, or a shopping flow that behaves more like an app than a page. These are real reasons to go headless.
Can your team actually maintain a framework that breaks every quarter? Hydrogen moves on the same calendar as Shopify's APIs. Someone on your team needs to own that upgrade cycle as an ongoing job, not a one-off project.
Do the apps you rely on even work headless? A large chunk of the Shopify App Store assumes a Liquid theme is injecting a script tag onto the page. Some apps talk to the Storefront API cleanly. Others need custom work, or don't support headless setups at all. Find this out before you start building, not after.
Is AI-driven shopping actually the goal? If your roadmap includes a shopping assistant or an AI agent that browses your catalog on a customer's behalf, that's a case where Hydrogen's direct connection to the Storefront API earns its complexity. That GraphQL layer is exactly what those systems need to read.
If most of your answers land on "not really," a solid Liquid theme built on Online Store 2.0 is probably the faster, cheaper, and safer path to the same goal.
How Teams Actually Land on an Answer
In practice, this decision rarely comes down to which framework someone likes more. It comes down to how complex the catalog is, how deep the team's React skills go, and how much of the App Store ecosystem the store leans on.
Teams that get this wrong usually make the call based on what's trendy, in the abstract, instead of checking it against their own app stack and how their content team actually works day to day.
When Lucent Innovation's Shopify store experts sit down with a merchant to answer this exact question, the audit almost always starts with app compatibility and how much merchants need to edit the site themselves. Architecture comes later. Those two things alone usually rule out one option before anyone even opens a performance benchmark.
However the decision lands, the same rule holds up: pick the setup your team can actually build and keep running for the next few years. Not the one that sounds best in a slide deck.
Have you shipped a Hydrogen store, or looked into one and decided against it? I'd like to hear what actually tipped the decision for your team.
Top comments (0)