Shopify Hydrogen vs Next.js + Storefront API

Hydrogen vs Next.js comes down to a single question: do you want a framework that already knows it is talking to Shopify, or a general-purpose React framework that you wire up to Shopify yourself? Hydrogen is Shopify's own React meta-framework, pre-configured for the Storefront API and deployed to Oxygen, Shopify's edge runtime — it gets you to a working cart and checkout fastest if Shopify is the only backend you will ever have. Next.js with the Storefront API is more work up front, but it gives you a framework that is not tied to any single commerce backend, deploys anywhere, and slots more naturally into a design system built around a component library like shadcn/ui. Neither is "better" in the abstract; the right choice depends on how tightly your storefront is going to stay coupled to Shopify.

The Short Version

If your storefront is Shopify-only, will stay Shopify-only, and you want to ship a performant, on-brand headless store without re-solving problems Shopify has already solved, choose Hydrogen. It ships cart, checkout redirects, analytics, and Oxygen deployment as defaults, not decisions you have to make yourself. If your storefront needs to combine Shopify product data with a CMS, other services, or a future backend swap; if you want full control over hosting (Vercel, your own infrastructure, a Kubernetes cluster); or if your team already has a Next.js design system and component conventions they don't want to abandon, choose Next.js + Storefront API. The tradeoff is genuinely that simple at the strategic level — the rest of this piece is about what that tradeoff costs you in practice.

What Hydrogen Actually Is

Hydrogen is Shopify's React framework, built on top of Remix's routing and data-loading conventions, and designed to run on Oxygen — Shopify's own edge hosting product. When you scaffold a Hydrogen project, you get a working storefront skeleton wired directly to the Storefront API: product pages, collection pages, a cart that persists via cookies, and checkout that hands off to Shopify's hosted checkout (or Checkout Extensibility, for stores customizing that flow). The framework encodes a lot of Shopify-specific knowledge for you — how carts should behave, how to handle Shopify's GraphQL pagination conventions, how metafields surface in queries, how localization and multi-currency work against Shopify's Markets feature.

The honest way to describe Hydrogen is: it is what you would eventually build by hand if you started from Next.js and the Storefront API and kept solving Shopify-specific problems for a year. Shopify has already made those decisions, tested them against real merchant traffic, and ships updates when the Storefront API itself changes. That is real, non-trivial value if you are building a Shopify-only store and don't have a reason to deviate from Shopify's own opinions.

The cost is coupling. Hydrogen apps deploy to Oxygen by default, and while Shopify has made self-hosting more viable over time, the framework's conventions (loaders, the cart context, the way sessions and checkout tokens are handled) assume Shopify is the backend. If you later need to merge in a second commerce backend, a headless CMS with its own data-fetching patterns, or a non-Shopify checkout, you are working against the framework's grain rather than with it.

What "Next.js + Storefront API" Actually Means

There is no Shopify-branded Next.js starter — this path means treating Shopify purely as a headless commerce backend behind its GraphQL Storefront API, exactly the way you would treat any other API-first service. You scaffold a standard Next.js app (App Router, React Server Components, whatever your team's current conventions are), write your own GraphQL client layer against the Storefront API using graphql-request, urql, or a hand-rolled fetch wrapper, and build product, collection, and cart logic yourself. You are also responsible for cart persistence (cookies or a session store), checkout handoff to Shopify's hosted checkout URL, webhook handling if you need inventory or order-status sync, and localization if you're selling into multiple currencies or languages.

What you get in return is a storefront that is not Shopify-shaped by default. Product data from Shopify can sit alongside content from a headless CMS, pricing or inventory from a separate service, or a design system that was never built with Shopify's conventions in mind. Because it's just Next.js, deployment is unconstrained — Vercel, a self-managed Node server, a static export where that fits, or any platform that runs a standard Node/edge runtime. For teams already standardized on Next.js and a component library like shadcn/ui, this path also avoids the friction of adapting Shopify's own UI conventions (built around Tailwind and Hydrogen's component patterns) to a design system that already exists.

Feature-by-Feature Comparison

Setup speed and opinionation

Hydrogen wins decisively here. Running npx create-hydrogen@latest (or the current Shopify CLI equivalent) gets you a running storefront with cart and checkout in minutes, because someone else already made the decisions. Next.js + Storefront API gives you an empty React app and a GraphQL endpoint — every decision, from folder structure to how cart state is modeled, is yours to make. That is not a criticism of Next.js; it's the nature of a general-purpose framework versus a purpose-built one.

Hosting and deployment flexibility

Next.js wins here. Hydrogen is designed around Oxygen, and while nothing stops you from running Hydrogen elsewhere, you lose some of the integrated benefits (preview deployments tied to Shopify admin, edge caching tuned for Storefront API responses) that make Oxygen the path of least resistance. Next.js deploys anywhere a Node or edge runtime is available, which matters if your organization has existing infrastructure standards, a multi-cloud policy, or needs to co-locate the storefront with other internal services.

Multi-backend and composable commerce

Next.js wins clearly if "composable" is a real requirement rather than a buzzword. If your roadmap includes combining Shopify's catalog with a separate subscriptions service, a PIM, a loyalty platform, or a CMS-driven content layer that spans multiple commerce backends, you want a framework that has no opinion about which backend is "the" backend. Hydrogen's conventions assume Shopify is authoritative for cart and checkout; bending that assumption is possible but works against the grain of the framework rather than with it.

Long-term maintenance and Shopify API changes

This one is closer to a wash, with a slight edge to Hydrogen. When Shopify ships a Storefront API version bump or changes recommended cart behavior, Hydrogen's maintainers update the framework and you get the fix through a dependency update. On a hand-rolled Next.js integration, your team owns tracking Storefront API version deprecations, GraphQL schema changes, and any shifts in recommended checkout patterns yourself. That's a real ongoing cost — not large, but not zero, and it compounds if the team maintaining the integration turns over.

Design system and component-library fit

Next.js has the edge for teams already standardized on a modern component library, most commonly shadcn/ui paired with Tailwind. Because shadcn/ui ships as copy-in source rather than an installed dependency, it drops cleanly into a plain Next.js app with no framework-specific adaptation. Hydrogen's own starter templates use Tailwind too, so the gap has narrowed, but a team with an existing design system built around shadcn/ui conventions, Radix primitives, and a component registry workflow will generally find it faster to wire that system into a blank Next.js app than to retrofit it onto Hydrogen's routing and data-loading conventions. This is exactly the kind of design-system-first storefront work Polo Themes' Figma UI kits are built to hand off cleanly into — the components translate to code the same way regardless of which React framework receives them.

Checkout and payments

Both paths ultimately hand off to Shopify's checkout — Shopify does not currently let a fully custom, non-Shopify checkout process card payments for a Shopify-originated order, for good reasons around PCI compliance and fraud tooling. Hydrogen wires this handoff (and Checkout Extensibility customization points) for you by default. On Next.js, you build the same handoff yourself: redirecting to the checkout URL Shopify returns from the cart mutation, and wiring any Checkout Extensibility customizations through Shopify's admin rather than in your own code. The end shopper experience can be identical either way; the difference is entirely in how much of that wiring your team writes versus inherits.

Where AI-Assisted, Design-to-Code Workflows Change the Calculus

The rise of AI design-to-code tooling — Figma-to-React generators, agentic coding assistants that scaffold components from a design file, and increasingly, the Model Context Protocol (MCP) as a way for tools like Claude or Figma's own AI features to reach into a live codebase — shifts some of the setup-speed advantage back toward Next.js. A meaningful part of Hydrogen's appeal has always been "less to set up by hand." When an AI agent can scaffold cart logic, GraphQL queries, and page routing from a well-structured Figma file or a clear spec in a fraction of the time it used to take, the gap between "Hydrogen gave me this for free" and "I built this in an afternoon with Next.js and an agent" narrows considerably.

This doesn't erase Hydrogen's advantage in Shopify-specific correctness — an AI agent still has to get cart mutations, checkout token handling, and Storefront API pagination right, and Hydrogen simply doesn't require getting those right because they're already solved. But it does mean the "time to first working storefront" argument for Hydrogen matters less than it did two or three years ago, especially for teams that already have strong, well-documented design systems an agent can work from. A clean, consistently-named component library and Figma file — the kind of source material Polo Themes' kits are built to be — is exactly what makes AI-assisted Next.js scaffolding fast and reliable, because the agent isn't guessing at structure.

A Decision Framework

Rather than a single verdict, work through these questions in order:

1. Will this storefront ever need a non-Shopify data source as a first-class citizen (a second commerce backend, a CMS driving significant page structure, a loyalty or subscription service)? If yes, lean Next.js. If genuinely no, Hydrogen's coupling costs you nothing.
2. Does your organization already have hosting standards that aren't Oxygen — a Vercel account every other project uses, an internal Kubernetes platform, a specific edge provider? If yes, Next.js avoids fighting your own infrastructure policy.
3. Do you already have a design system built around shadcn/ui, Radix, or a similar component-first approach that the team doesn't want to abandon or heavily adapt? If yes, lean Next.js — the integration friction is lower.
4. Is speed to first launch the dominant constraint, with a small team and no near-term plans to complicate the backend? If yes, Hydrogen's batteries-included setup is hard to beat.
5. Does your team want Shopify to own upgrade risk for cart/checkout conventions, or do you want full control (and full responsibility) over that layer? Hydrogen for the former, Next.js for the latter.

Most teams land on Hydrogen for a straightforward, single-backend Shopify store where speed matters more than architectural flexibility, and on Next.js + Storefront API when the storefront is one piece of a larger system, or when an existing design system and infrastructure footprint make a general-purpose framework the lower-friction choice. Neither path is more "modern" than the other — they're solving for different constraints.

Where Polo Themes Fits Today

To be direct about scope: Polo Themes currently sells Figma UI kits and Shopify OS 2.0 themes — we don't yet sell a Next.js starter, a component registry, or MCP-native templates for either Hydrogen or a custom Next.js storefront. That said, the design work underneath a Hydrogen build and a Next.js build is largely the same problem: product pages, variant pickers, cart drawers, and collection grids that need to look intentional rather than default. If you're evaluating either path and want a head start on the interface layer, our Figma kits are built to translate cleanly into component code regardless of which framework ends up consuming them — that separation of design system from framework choice is exactly why the Hydrogen-vs-Next.js decision doesn't have to be made before the design work starts.

Frequently Asked Questions

Is Hydrogen required to build a headless Shopify storefront?

No. Hydrogen is Shopify's recommended path, but the Storefront API is a public GraphQL API that any frontend framework can call. Next.js, SvelteKit, Nuxt, or a plain React SPA can all build a fully headless Shopify storefront without Hydrogen.

Can I self-host a Hydrogen app instead of using Oxygen?

Hydrogen is built on Remix conventions and can, with effort, run outside Oxygen, but Oxygen is the path Shopify optimizes for and documents best. If self-hosting on your own infrastructure is a hard requirement, a plain Next.js + Storefront API build usually involves less fighting against framework assumptions.

Does switching from Hydrogen to Next.js (or the reverse) require rebuilding the checkout?

No — both paths hand off to Shopify's hosted checkout (or Checkout Extensibility customizations configured in the Shopify admin). Checkout logic itself doesn't move with your frontend framework; what changes is how much wiring code your team writes to get the shopper to that handoff correctly.

Does using Next.js instead of Hydrogen mean giving up performance?

Not inherently. Well-built Next.js storefronts on the Storefront API can match Hydrogen's performance with proper caching, image optimization, and server-side rendering discipline. Hydrogen's edge-tuned defaults on Oxygen make good performance easier to get by default, but they don't make it exclusive to Hydrogen.