Shopify Hydrogen in 2026: framework-agnostic core, explained

Shopify's Spring '26 Edition for developers shipped a developer preview of a rebuilt Hydrogen, and it is the kind of change that resets a lot of assumptions. The headline: the commerce logic that used to live inside React Router now lives in a framework-agnostic core you can call from any JavaScript framework. Hydrogen is being repositioned from a framework you adopt wholesale into a toolkit you reach into. If you have been searching whether Hydrogen is still React or whether your existing storefront is obsolete, this post is the orientation.

What Hydrogen was

Until this release, Hydrogen was Shopify's React-based headless commerce framework. It was built on Remix, the framework from the creators of React Router, with server-side rendering, nested routes, and optimistic UI. Commerce concerns (the cart, the Storefront API client, money formatting, analytics) were woven into that React Router app. You got a fast, opinionated stack, deployable to Shopify's Oxygen hosting, as long as you were building in React.

That coupling was also the ceiling. If your team builds in Svelte, Vue, or Astro, Hydrogen was not for you. You could still hit the Storefront API directly from any framework, but you gave up the cart logic, the Shop Pay handling, the analytics, and the rest that made Hydrogen worth using. The commerce primitives and the React framework came as a single package.

What changed in Spring '26

The preview pulls the commerce logic out of React Router and into a standalone core. The official update describes the new Hydrogen as a toolkit, not a framework: a framework-agnostic core of Shopify storefront primitives, thin bindings for the framework you are using, and agent skills that teach your coding agent how to wire it together. Three layers instead of one monolith.

• The core is plain JavaScript. It ships cart, product, and collection primitives, money formatting, Shop Pay, a typed Storefront API client, and first-party analytics with consent handling. Because it is framework-neutral, the docs note it works with Next.js, React Router, SvelteKit, Astro, SolidStart, or Nuxt.
• Bindings are thin and per-framework. React bindings ship in the preview; other frameworks use the core primitives directly while their bindings are built out. The binding is the small adapter layer, the commerce logic is no longer tied to it.
• Agent skills ship with the package. These are skills a coding agent (in editors like Claude Code, VS Code, or Cursor) uses to scaffold a storefront for you, guiding it through wiring up each part. Shopify is treating storefront scaffolding as a machine-executable capability rather than human boilerplate.
• It deploys anywhere you can call fetch. The update lists Oxygen, Vercel, Cloudflare Workers, Node, or Deno. Server-driven cart and request handlers work before client-side JavaScript loads, with optimistic UI layered on top.

Why Shopify did this

Two forces. The first is flexibility. Tying commerce primitives to one React framework excluded every team standardized on a different stack. Moving the logic into a plain-JavaScript core means the cart, Shop Pay, and analytics are reusable from wherever you render, and Shopify maintains one core instead of re-implementing commerce per framework.

The second is agents. A framework-agnostic core with documented primitives is something a coding agent can compose reliably. The shipped skills exist so an agent can scaffold a storefront, picking the right primitive and wiring it correctly, rather than guessing at a large opinionated framework. This is the same pattern across the Spring '26 developer story: build platform surfaces that both humans and agents can drive. We unpacked the rest of that release in our Spring '26 Edition for developers breakdown.

What it means for you

The decision that matters has not changed: where should the commerce logic live? Hydrogen being more flexible widens the headless option, it does not make headless the default answer. For most stores, a Liquid theme on the Online Store is still the right call, faster to ship, cheaper to maintain, and it inherits the storefront, checkout, and app ecosystem for free.

• Stay on a Liquid theme when the storefront is the product surface, you want the app ecosystem and theme editor, and the team's leverage is in merchandising and conversion. This is most stores, and it is not a compromise.
• Reach for headless / Hydrogen when you need a custom front end Liquid cannot express, a non-Shopify content or design system in the driver's seat, or multiple front ends sharing one commerce backend. The Spring '26 core makes this reachable from frameworks beyond React.
• Consider an app or a Function when the logic is backend behavior (custom discounts, validation, fulfillment rules) rather than presentation. That belongs in a Shopify Function or app, not the storefront layer, regardless of whether the front end is Liquid or Hydrogen.

If you maintain an existing React-based Hydrogen storefront, nothing breaks today: this is a preview alongside the current stack, not a forced migration. The skill that ages well is not memorizing the new API surface, it is the judgment to decide which layer a piece of logic belongs in. That judgment is exactly what we argue for in learning Shopify development in the AI era.

What to watch before you commit

Treat this as a direction signal more than a tool to deploy this week. The signal is clear: Shopify wants commerce primitives that are framework-neutral and agent-composable. Read the official Hydrogen developer preview update and the changelog entry for the current state, and check the Hydrogen docs before building anything you intend to ship.