I've spent the last few years living inside headless CMS platforms: Contentful, Strapi, content modeling, migrations, and the React and Next.js frontends that sit on top of them. Lately I've been pointing that experience at Shopify, and the surprising part is how little of it I had to unlearn.
Commerce platforms and content platforms solve different business problems, but the frontend problems are the same ones: where does the data come from, who controls the layout, and how do you keep the UI from depending on a vendor's response shape?
A Liquid theme is the default path. The store is rendered and hosted by Shopify's Online Store, and merchants rearrange pages in the theme editor. A Hydrogen storefront is a custom React app built on React Router, talking to the Storefront API and deployed to Oxygen, Shopify's edge hosting.
Neither is "better". A theme is often the right answer when editors need control and the design fits the model. Hydrogen earns its extra engineering when the experience needs to go beyond what a theme can express. Being comfortable in both is what makes the recommendation honest.
A JSON template lists which sections appear on a page and in what order. Each section is a Liquid file with its own schema. Blocks are the smaller pieces inside a section that merchants can add, remove, and reorder. If you have used flexible components or dynamic zones in a headless CMS, this will feel familiar.
The schema is the contract between the developer and the merchant. It decides what the editor can change, and everything else stays consistent. That is the same idea as a content model, just expressed next to the markup.
In my previous post I argued that your UI should depend on your application's data model, not the CMS's. That rule holds for Shopify too.
And an adapter that maps the response to the same Product model the components already use:
doesn't know or care whether the data came from Shopify, Strapi, or Contentful. If the product data moves later, only the adapter changes.
The vocabulary changes, the thinking doesn't. Content types become metaobject definitions, custom fields become metafields, flexible page composition becomes sections and blocks, and the delivery API becomes the Storefront API. Add migration experience on top (mapping one content model to another without breaking the frontend) and a lot of Shopify work starts to look familiar.
What I care about when building storefronts Performance. Product and collection pages are where Core Web Vitals turn into revenue, so image handling, script weight, and render cost get attention early. Accessibility. Variant pickers, carts, and checkout entry points have to work with a keyboard and a screen reader. Merchant experience. A schema that makes sense to an editor is part of the product, not an afterthought. Boundaries. Keep platform-specific data at the edge, and let the UI depend on your own model.
I'm currently looking for frontend roles, with a focus on Shopify: theme development with Liquid, and headless storefronts with React and the Storefront API. If you're building in that space, I'd like to hear how you split the work between themes and headless.
Which do you reach for first on a new store: a Liquid theme, or Hydrogen? What tipped the decision?