Skip to content(if available)orjump to list(if available)

How we built Hydrogen, a React framework for building custom storefronts


All of this would be far more interesting to me if it weren’t based on React. Almost any other technological choice would have been better, from my perspective. I get it, React developers are cheap because people have bought into the React hype.

To me, though, especially with hooks, React creates a bizarrely deep object tree that is impossible to reason about in comparison with pretty much every other tooling that exists.


React was first released 9 years ago, more than a “hype”, it is still a great success! (And source of my economic wealth too)

- a cheap developer


I’m glad you like it. Someone has to, I guess.

I can’t stand it and find all the promotion on it to be promising far more than it delivers. It’s heavier, slower, less comprehensive, and less comprehensible than either Vue, Svelte, or most Vanilla JS implementations of component-oriented sites that I’ve seen.

Every single thing about React bothers me, from hooks to JSX (which is so much worse than meaningful templates), and I’d rather use something that makes me happy.


> I’m glad you like it. Someone has to, I guess

Millions of people and companies do. For mostly one reason: Getting started is incredibly simple. React's surface area is incredibly narrow. Almost anything in it is just JavaScript. Hooks or Classes? Syntax inside JSX? Just normal JavaScript. With hooks, there are basically two that can do 99% of what you want to do.

> which is so much worse than meaningful templates

Why? There is a zero bullshit approach here. No magic syntax. No "v-for" or two way binding. No receiver patters or context parameters.


After using Dominate, Hiccup, Slim, and JSX, CDK, I have no desire for templating HTML (or anything) on the level of strings anymore. It’s so stupidly clunky, doesn’t compose well, is hard to mutate, hard to test, you have to deal with all the weirdness of your templating language, logic is split across your controllers and templates.


You can always reason quite well about React if you follow good conventions. It's a tradeoff of complexity and flexibility.


Both Vue and Svelte are both lighter-weight, faster, and have more features than base React while being less complex and more flexible than React.

IMO, Vue 3 has made a mistake buying into the whole hooks nonsense, and I find it less usable than Vue 2. On the other hand, Vue 3’s implementation is more comprehensible than React’s.


Something I don't think Vue has ever got right was the incomprehensible stack trace at the sight of any error. Or maybe I'm missing something.

After working for a few years in reactive frameworks like Vue and Svelte, I feel I am longing for the simplicity of React now.


> while being less complex

Idk, I found the svelte reactivity model a little confusing.


I'd quit any job that made me work on a jQuery/vanilla JS labyrinth. React is the best thing to ever happen to frontend development and from my perspective most contrarians on the topic haven't taken the time to learn React and simply immediately dismissed it.


React and JSX are, at best, mediocre. I consider it much more like C++: you’re much more likely to blow your foot off with React than with anything else. The codebases are excessively complex, completely magic, and impossible to debug in comparison to pretty much any other comparable framework, including modern Vanilla JS (with or without Web Components).

I agree with you about jQuery. It had its place. It’s painful to encounter now, especially since it can screw up any other framework that you want to put into a website.


Maybe you've worked on the wrong React codebase. It's come a long way from the Redux & class-based monolith structures from early React.

The components I work on and write are all narrow in scope, self-contained and completely testable with no crazy side effects + minimal global scope.

The easy path on React is small functional components.


React is * old * (in the frontend world), stable and very very well known. It is a solid, responsible choice to build your framework on top of React in 2022.

You can upgrade a 7 year old React app with very little fuss. Unfortunately, you cannot say the same about Vue or any of the modern libraries. They also have no track record to indicate they will exist 10 years down the line, but I'm pretty sure my React apps will still be fine.

That being said, I'm very excited about SolidJS[1] and the other modern libraries that use JSX.



Vue is about as old as React, and upgrading a React app from class-based to hook-based is as much, if not more, work than going from Vue 2 to Vue 3 (but I don’t want to do either one).

I’m exceedingly unexcited about anything that uses JSX, which is a blight on the landscape.


If they had used any other library there would have been a comment like this telling them they're doing it wrong.

Same thing any time WordPress does anything notable.

Teams make tech decisions based on multiple factors. Sometimes the ones like "bizarrely deep object tree that is impossible to reason about" are found to be less important. Because at the end of the day websites are for the wider public audience, who aren't affected by bike shedding


Also react-dom.min is 15 times larger than solid/preact/lit-html/svelte, is on the bottom of every perf benchmark, and yet we pretend to have engineering mindshare. It feels like new coming kids would just skip engineering school/university just fine for working in this industry. Disappointed.


It would not work with other tech. It is a multi year project and such require reliable tech more than anything. Any other tech could become a liability in a couple of years


React developers are cheap? So much wat.


I don't know why you're downvoted. React jobs are indeed among the best paid front end jobs.


But entry-level React jobs are also very common. There are entire coding schools dedicated to teaching React far more than general JS.


Cool to see Shopify using Vite and contributing back to that project. I didn't know it would be so useful with React since it came out of the Vue world. But I've now read that Evan wanted to make it open to all frameworks which is the best approach.

My life has been made a lot easier since I ditched Webpack for Vite. Faster build times, way less complexity, cleanly breaks up projects into small .js files on a per-route basis etc.


I just started using Vite, and completely agree. I haven't explored it much but it's super fast so far. Like literally just a few minutes ago, I decided that I wanted a multi-page app instead of an SPA. Took me 5 minutes, didn't need to set up any additional entry points or chunks or anything. Fantastic.


Yeah it's basically plug-and-play. Unlike Webpack which required careful configuration unless you use one of the webpack-starter-kits with a thousand dependencies and don't need to build complex apps.


I would love to see more in-depth explanations about Oxygen [0]. I'm currently creating a similar runtime [1] based on V8 Isolates so that would be interesting to compare.

[0]: [1]:


Look for a blog post about Oxygen in the coming weeks! Initially, we're partnering with Cloudflare using Workers for Platforms [0] so Oxygen's runtime shares many of the same APIs you'd expect to see in a Cloudflare Worker [1].

[0]: [1]:


> initially

Does that mean you want to roll out your own runtime in the future?


Isn't this the nature of trying to capture more profit? Of course, once proven, they would like to vertically integrate; I take this as true in all circumstances


Certainly not out of the picture, but Cloudflare is a terrific solution for us right now.


Same same, the SSR piece means they’d have to build some kind of storefront PaaS, and it wasn’t immediately obvious what the enabling runtime is (or more interestingly for me, how it ticks).


I really don't like the idea that Shopify adopted React so deeply (Polaris is an example), not because I am a Vue developer but I would prefer Shopify to not be so opinionated about any framework.

VanillaJS is very advanced nowadays.


SalesForce built their Lightning framework with web components. It's a complete dumpster fire. Front end has settled on React for a reason; it's the best way to build UIs for the web.


Liquid is a love letter to vanillaJS. That will always be the shopify default. Ecommerce is perfect use case for the web native.




I'm on the Shopify Hydrogen team. Happy to answer any questions.


I’m not familiar with shopify but I’m about to start a shopify project for a client.

Can you elaborate on what the difference is between Hydrogen and a custom theme? Other than the tooling and template language I’m struggling to understand the conceptual differences.


Hydrogen is essentially a headless storefront, you have complete control over how your storefront is rendered, but it does come with boilerplate and helpers for some standard primitives that most people will want (e.g. carts).

Custom themes allow you to template on top of the Shopify front end, giving you less control.


Hello, Thanks for taking question.

I am a backend developer and lightly familiar with what React bring in frontend development. I have not familiarity with Nextjs.

Given what I know, where does Hydrogen fits into the picture? Why shouldn't I stick to sever side rendered pages when developing Shopify app?



If liquid is what you know and love, 100% stick with it. Liquid isn't going away, and there are plenty of opportunities to build out liquid storefronts. Hydrogen is built for custom storefronts that need more flexibility than what is available in a liquid theme. It's entirely customizable. Hydrogen has better performance capabilities as well, because it can be stream rendered to the client.

"Why shouldn't I stick to server side rendered pages?"

Hydrogen is still server rendered. Server components themselves never execute in the browser.


Hi! Great work so far. Does the team have a vision for a way to standardize the front-end part of shopify apps? That seems to be the really tricky part of a appstore-based platform going headless.


Hi, do you think is the right time to start developing an ecommerce with Hydrogen? It sounds you're still in a beta phase where api may change frequently.


I do! As of this week, we're at stable v1 and out of developer preview.


Not on this team, but have heard nothing but praise internally. Congratulations to the Hydrogen team on shipping!


I have always wanted to use React with Shopify, but I feel binding the data manually from the Shopify API via GQL is very unergonomic. You have to understand Shopify API way deeper than usual to get started. There should have been basic but non-optimal ways to get data for 90% of the use cases already included. The GQL query they showcase is just complicated compared to the liquid way.


For anyone struggling with Tailwind, I would recommend Tailwind DX[0]



This is huge, and I think it could have implications beyond the ecommerce store. I know it relies heavily on React Server Components, is part of the long tail on this due to the fact that those haven't shipped in stable yet?


Correct, we're shipping with an initial version of React Server Components (RSC) that works in Vite and uses file suffixes. Hydrogen provides missing pieces to the current version of RSC, like data fetching and other dev tooling.

We're working to align with Vercel on improving the conventions of server modules (e.g. dropping the filename suffix): and we anticipate to release future versions of Hydrogen and Next.js that use something like boundary annotations instead.


Thats pretty cool!

To say this though, I prefer the file extensions bit, e.g. `.client.ts` and `.server.ts` over directives. Directives aren't super discoverable at a glance, and I think will lend themselves to a lot more headache in terms of engineering practice.

I realize its better for compilers probably, but it hinders DX for large applications IMO.


Initially we'd proposed just dropping `.client.` and keeping `.server.`. This area overall is still being worked out, and the two options aren't necessarily mutually exclusive.


That's good feedback. The directive approach relies much less on initial discoverability and tedious work which enables it, like naming each and every JS module a certain way up front. Instead, it relies on error handling and developer response/correction. I'm definitely curious to see whether that tradeoff is worthwhile.


The number 1 thing you guys need to check is how do static, vs react, vs any other framework or front end approach do for your users in SEO. Then build with that approach.


Thankfully Shopify has a pretty massive SEO team who we've been working very closely with. Static often doesn't work well for many parts of ecommerce — but we support both sub-request and full-page caching (More here: and we worked with Google to make sure we're doing the right thing from their perspective — this is the recommended approach, which we took:


One big problem we have with shopify is users don't stay logged in for more than 24 hours. Do you guys fix that with hydrogen?


You can use hydrogen and the storefront api to renew the customerAccessToken:


Thanks for the reply. The scenario is a customer logs in. They come back 4 days later, and we want them to remain logged in and not have to re-login.

According to this mutation, you must renew the access token before it expires (presumably for just another 24 hours). So I don't think this solves the issue -- we want users to stay logged in for more than 24 hours -- aka logged in for like a month by checking a "keep me logged in" box.

What is the strategy for this basic use case?


Just learned that the token lasts for 6 weeks, so the issue might lie in how you’ve implemented the session.

Take a look at the hydrogen demo store, auth is implemented using the customer access token and Hydrogen’s CookieSessionStorage:


Going to take this as an opportunity to ask, has anyone here worked with

It looks like a very competent solution but would like to hear from actual users