Hydrogen with Josh Larson

Episode Description

Josh Larson introduces Shopify's Hydrogen framework, an opinionated React framework for building custom headless storefronts with server components.

Episode Summary

This episode features Josh Larson from Shopify discussing Hydrogen, a new opinionated React framework designed specifically for building custom headless storefronts. The conversation begins with Josh's background, from tinkering with HTML during the Myspace era to building Flare React, an experimental framework for running React on Cloudflare Workers, which ultimately led to his role at Shopify. Co-host Christopher Burns shares his own extensive experience building and maintaining a headless Shopify store, detailing the pain points of stitching together Gatsby, Contentful, Algolia, and Shopify — and eventually migrating to Next.js — which perfectly illustrates the developer experience problems Hydrogen aims to solve. Josh explains that Hydrogen differs from general-purpose frameworks like Next.js and Gatsby by being hyper-focused on commerce, leaning into dynamic server rendering rather than static generation, and adopting experimental React Server Components and streaming SSR with suspense to enable component-level data fetching. He also introduces Oxygen, Shopify's forthcoming hosting platform that runs on V8 worker runtimes co-located with Shopify's databases for fast data queries. The discussion covers third-party integration strategies, the GraphQL-only storefront API, checkout customization limitations, and Hydrogen's open source community efforts, painting a picture of a framework betting heavily on the future of React.

Chapters

00:00:00 - Introductions and Josh's Background

The episode opens with hosts Anthony Campolo and Christopher Burns welcoming Josh Larson to discuss Shopify's new Hydrogen framework. Anthony frames the conversation by noting that Hydrogen comes from an established company with significant credibility in the commerce space, distinguishing it from the many other frameworks they've covered.

Josh shares his journey into tech, starting with HTML and CSS during the Myspace era in rural Iowa, studying journalism in college, and working in WordPress and PHP development at an ad agency. He describes discovering Vue.js as his entry into modern JavaScript frameworks, then moving to Vox Media before diving into React around the time hooks launched. This path led him to build Flare React, an experimental framework for running React on Cloudflare Workers without an origin server, which caught Shopify's attention and led to his recruitment.

00:02:52 - Flare React and the Challenges of Worker Runtimes

Anthony asks Josh to elaborate on Flare React and the specific challenges of running React inside Cloudflare Workers. Josh explains that a V8 worker runtime is much closer to a browser environment than to Node.js, meaning common Node built-in modules like fs are unavailable, which made Next.js largely incompatible with workers at the time.

Beyond runtime compatibility, Josh highlights broader ecosystem challenges such as data storage and getting popular third-party libraries like Styled Components to function properly in these environments. He suggests the ecosystem will eventually need to align on compatibility mechanisms between Node and worker runtimes, though most library authors aren't yet thinking about this gap. The conversation transitions toward Hydrogen itself.

00:04:31 - What Is Hydrogen and the Headless Commerce Problem

Josh introduces Hydrogen by explaining the rise of headless commerce and Shopify's previous hands-off approach of simply offering an API without much developer tooling. After taking a hard look at the developer experience, Shopify found that building headless storefronts with their existing tools was unnecessarily difficult, which led to the creation of Hydrogen and its companion hosting platform, Oxygen.

He defines Hydrogen as an opinionated React framework using server components and streaming SSR, designed to make building dynamic custom storefronts straightforward. Christopher then shares his own lengthy experience maintaining a headless Shopify store cobbled together from Gatsby, Contentful, and Algolia, detailing how build times ballooned, Gatsby broke under scale, and the migration to Next.js — while successful for end users — was painful for developers. Josh empathizes, noting that rate limits on static builds of large product catalogs were a known issue Hydrogen was designed to address.

00:11:27 - Hydrogen vs. Gatsby and Next.js

The conversation shifts to how Hydrogen compares technically and philosophically to Gatsby and Next.js. Josh explains that while Gatsby began as a static site generator and Next.js evolved from server rendering to incremental static regeneration, Hydrogen takes the stance that dynamic server rendering is the right approach for commerce, where merchants need personalization, A/B testing, and customer-specific product funnels.

Christopher summarizes that Hydrogen is specifically opinionated for Shopify e-commerce, and if a merchant fits that use case, the framework's opinions will serve them well. This naturally raises the question of hosting, which leads into the discussion of Oxygen and how Shopify is positioning itself to handle the full stack from framework to deployment for custom storefront developers.

00:16:07 - Oxygen Hosting and the Full Stack Vision

Josh describes Oxygen as Shopify's hosting platform for Hydrogen storefronts, built on a V8 worker runtime similar to Cloudflare Workers. The key advantage is that Oxygen runs in Shopify's own data centers, co-located with their databases, enabling millisecond-level data queries without network hops. He notes that Shopify has been hosting storefronts for over a decade via Liquid themes and expects most merchants will continue using Liquid.

Christopher frames Shopify's strategy as tackling three distinct business areas — framework, hosting, and API integration — simultaneously for the specific use case of custom Shopify storefronts. Josh agrees, emphasizing that being constrained to a specific purpose lets them make sharper decisions than general-purpose platforms like Vercel or Netlify, which must support a wide range of use cases. The discussion also touches on third-party compatibility, with Sanity highlighted as an early integration partner that built a plugin for Hydrogen's developer preview.

00:22:43 - Checkout, React Server Components, and Streaming SSR

Christopher asks about custom checkout experiences, and Josh explains that Hydrogen's current focus is the pre-checkout storefront experience, while Shopify's existing checkout is battle-tested and optimized. The conversation then moves into React Server Components, which Josh describes as the missing piece that let Hydrogen avoid inventing proprietary data-loading patterns like other meta-frameworks had done.

Josh explains the major shift he sees coming: moving from route-based data loading to component-level data fetching wrapped in React suspense boundaries, enabling streaming responses with skeleton fallbacks rather than waiting for all data before rendering. He describes how Hydrogen's Use Shop Query hook abstracts away the implementation details, letting Shopify swap underlying data-fetching strategies as the React team refines Server Components without breaking changes for developers.

00:31:04 - Open Source, GraphQL API, and Closing Thoughts

Christopher asks about Hydrogen's open source approach, and Josh explains that most framework direction discussions happen publicly, with third-party developers already contributing. He notes that living on the bleeding edge of server components means the team will need to actively collaborate with popular library maintainers to ensure compatibility, sometimes by directly opening pull requests in external repos.

Anthony raises the GraphQL-only storefront API, and Josh discusses how GraphQL enables precise queries but creates challenges when Hydrogen's pre-built components request more data than some merchants need. Christopher shares his experience with API versioning quirks like "price V2," and Josh reveals that Shopify's CEO Toby personally rebuilt his original snowboard shop with modern tools and discovered many of the same pain points, motivating upstream improvements. The episode wraps with Josh pointing listeners to Hydrogen's documentation, GitHub repo, and Shopify's open positions.

Transcript

00:00:00 - Josh Larson

Hello. I'm talking a little bit, and this is about my talking temperature.

00:00:15 - Anthony Campolo

Josh Larson, welcome to the show.

00:00:17 - Josh Larson

Thanks for having me. Nice to meet you all.

00:00:18 - Anthony Campolo

We're going to be talking Shopify and Shopify's new framework, Hydrogen. This will be really exciting because we have talked about so many frameworks on this show, and this is one that is being put forward by a very well known, very established company with a lot of cred. It's similar to some that we've talked about and probably different in its own unique ways.

But before we get into the framework, we'd love to know a little bit about yourself, how you got into coding, how you got into Shopify and this framework, and all that.

00:00:52 - Josh Larson

I live in Iowa. I grew up out in the country and got into computers around the Myspace era, which I think a lot of us have. I started tinkering with HTML and CSS with limited knowledge.

I ended up going to school for journalism, nothing related to computer science, but in school I met some really cool people and took a student job that let me learn more about web development and PHP specifically. After school, I got a job in marketing roles at an ad agency, working primarily in WordPress development. So a lot of fun PHP stuff.

That's a huge world out there that we don't think about a lot as JavaScript developers, typically. That was a really good experience, and I started learning JavaScript. I had been more of an HTML, CSS, PHP person before that.

I think Vue.js was my first introduction into the more modern JavaScript framework landscape. I went to Vox Media where I focused on the engineering side.

00:01:50 - Josh Larson

So putting ads onto websites that we all adore had some interesting challenges there. I started diving into React about the time hooks were introduced, and that was a game changer for me.

A year and a half ago, I started experimenting with building a framework that would run on Cloudflare Workers because I thought it would be cool if you could server-side render, or really edge render, a React framework on Cloudflare Workers without needing an origin server. It was like a week-long experiment. Flare React was born, which is one of my open source projects, and I think from that exposure I got to meet a lot of cool people.

One of the benefits there was that I got recruited and joined Shopify. A few months into Shopify, we started working on this project called Hydrogen, which is kind of similarly built as a way to build custom storefronts for merchants who want to build custom storefronts. It happens to be built in a similar way to Flare React, in that it's built for V8 runtimes or worker runtimes.

00:02:47 - Josh Larson

That's a very short CliffsNotes version of my entire life as it relates to tech.

00:02:52 - Anthony Campolo

It's really cool that you did Flare React, actually, because that is a framework that I've heard of and had been wanting to check out. If you could talk just a little bit more about what that is and what the challenges are with running React on Cloudflare Workers just by itself, what necessitates a framework to do that?

00:03:11 - Josh Larson

Flare React was an experiment to see if I could run a Next.js-like framework on the edge in Cloudflare Workers. The impetus was to learn how Next.js works and how I could copy Next.js, and that was super interesting for me.

The biggest challenge, like you mentioned, is getting JavaScript to run in a workers runtime. A V8 workers runtime is much more similar to running JavaScript in your browser than it is running in Node.js. For years, Next.js had been built primarily as a Node.js framework, and so you have references to Node built-ins, like the fs module, that are not present on a workers runtime. So really, in a workers runtime, you can't require anything that made Next pretty incompatible with workers at the time.

There are other challenges too, like how do you do data storage? How do you interact with really popular third party frameworks? If I pull in Styled Components, how do I make that work in a framework really nicely? They all have unique challenges that we don't really have answers for yet.

00:04:09 - Josh Larson

For a lot of third party ecosystem compatibility between Node runtimes and browser-like runtimes, which are like worker runtimes, I think that's an area that we'll see the ecosystem explore further and maybe align on a compatibility mechanism. Like, hey, this works in both these types of things. But I think most developers also aren't thinking about that a whole lot. They think about their thing and not all the other instances where it can run.

00:04:31 - Anthony Campolo

We'll drop links to some Flare React stuff in the show notes. But you were here to talk about Hydrogen, so why don't you give us a definition of what Hydrogen is and why it was created?

00:04:42 - Josh Larson

There's this thing called headless commerce. It's the hotness. Right now, everyone wants to do headless, and every company wants to do their version of headless. Up until this point, Shopify has been kind of like, okay, we have an API, you can use it. Good luck.

I think last year we really took a hard look at that stance and our approach, did some explorations, and found that it's not super easy for developers to do quote unquote headless with the tools that we've given them. We can dive into those issues as much as we want, but out of that exploration came Hydrogen and then Oxygen, which we can also touch on.

Hydrogen is an opinionated React framework that lets you build custom storefronts really easily. It uses React. It's built with modern, future-facing things like server components and streaming server-side rendering that we believe is the answer to building dynamic custom storefronts in 2022. We've spent the last year building out Hydrogen, and we've opened it up to developer preview, I think, in November.

00:05:40 - Josh Larson

And so we're getting a lot of feedback. People are breaking things and finding out what works, what doesn't work, and what things we need to correct. Our goal is to get it into a stable version this year and have folks really building production storefronts on it.

00:05:53 - Christopher Burns

This is an area that I'm actually super interested in. Sometimes the users don't know, but obviously I run my own company. Sometimes I do side work, and one of the biggest side work projects I've worked on and maintained is actually a Shopify store, so it's e-commerce. I've maintained it now for about three years. It's always been on Shopify and it's always been headless.

So obviously when you say we looked at this ourselves and noticed that it wasn't a good experience, I felt this pain. It's not always been Shopify that I think the problem has been. I think Gatsby was also the problem at some times.

But the biggest thing about it is, and this is the whole crux of why I'm bringing this up, when I first looked at this three years ago, Gatsby 2 was the hot thing. Shopify, you could run Shopify in headless mode, and people had simple tutorials explaining how to do it. This client came to me and was like, you know, I want a better storefront.

00:06:51 - Christopher Burns

They tested their MVP and they tested that this store could work, so they wanted to go bigger. So I was like, I'm big into Gatsby right now, I know Shopify, I will just merge this all into a headless Shopify store. The biggest thing about it that I think is really important to mention is that I think I did not use Shopify right. So I started building this ugly beast that works really well for the end customers.

To Shopify, or the other companies whose products have all been amalgamated together, it's really ugly and there's a lot of hacks in there. But to the end user experience, it's one of the best stores that this company has ever come across, if that makes sense. You've got Shopify as the headless payments shopping system, then you've got Contentful on top of that. That has a second layer of all the extra product descriptions and custom tables and review stuff. Then you've got Algolia handling a massive filtered search system with custom variables.

00:07:55 - Christopher Burns

You had Gatsby 2 holding it all together, and it was just this massive conglomerate of multiple products. It's the Jamstack way of: don't build it yourself, just use APIs. To the end goal, it worked really, really well.

And this is the caveat here. As the website got bigger and bigger and more products were added, more photos were added, Gatsby 2 was slowing down and it was breaking, and it wasn't a good experience up until about six months ago. This is where it gets interesting, where it was like, it's not good enough anymore. I'm spending more time just trying to work out why it's not working than building.

So I go, I'm throwing in the towel. I'm going to rebuild all of the custom logic on Next.js because it's enterprise. You know, Disney Plus used Next.js. I've used Next.js. I know what I'm doing. Next.js has its own CMS starter that they call. How hard could it be? So you start down the path again.

00:08:49 - Christopher Burns

And that path still took me about a month just to rewrite all the underlying logic of connecting these three products together. Instead of having a massive build step, now it's incrementally generated and still a really, really good end user experience.

But the developer experience, oh my god, is it nuanced. I think nuanced is the word. And as you were saying, when you spent time reviewing the headless system, you start seeing these flaws a lot bigger and brighter.

You make do because your customers use Shopify. You're not going to be like, well, I think you should chuck everything out the window and start again on an alternative platform, as many are. While I was actually building this, Hydrogen got launched. It got into this developer preview, and I was like, oh, have I made the wrong decision? I've waited like months to rebuild this, like months and months. And then just as I start rebuilding it, this is when Gatsby 4 is out. So I've completely ditched Gatsby and went to Next.

00:09:47 - Christopher Burns

And this is like, oh, have I made the wrong decision? But in hindsight, it's still the right decision. Not because Shopify can't bring out something better, but it's working to the customer's needs. And that's what I'm really trying to get down to. The developer experience is ugly, but to the customer and the end customer, it works great.

And that's my whole massive story of why this is a really infuriating area, and I can't wait to see what Hydrogen does to improve that.

00:10:15 - Josh Larson

Thank you for sharing that. That's super good to hear about your experience, and I'm sorry it's not been great. Like you said, that's what we kind of discovered.

It's the storefront API with Jamstack. You think about static, right? Lean into static as much as possible. But we found that you get rate limited when you need to build out hundreds or thousands or hundreds of thousands of products. How do you do that? You want to have a good storefront for customers, and customers don't care about what tech you're using as long as they can order their thing.

But Shopify wants to make commerce great for merchants. We're not in the business of building frameworks, general purpose frameworks, or anything, but we found that we weren't necessarily doing a good job of that because of all that build time like you mentioned.

So I'm also very interested to see, is Hydrogen going to work for folks? I think obviously I hope it does. I think you touched on really important things too, like custom storefronts require a lot of other pieces than just loading up a product and being able to add it to cart. People like to host content in other places like Contentful or Sanity, and you have loads of other third party integrations that you might need to use.

00:11:16 - Josh Larson

And that's just the reality. We want to make it as easy as possible to live in that world. I think it benefits Shopify to do as much as we can to make it easier for developers to get going on that path.

00:11:27 - Christopher Burns

Yeah. I think it's actually really interesting that, as we talk about this, the headless option to Shopify was not its first option. When we talk about all the competitors, it is their USP. It's their thing. They built the headless commerce platform first. There's tons of them.

But Shopify has been going for, what, ten years? I think off the top of my head. And they've had the theme system. I think it was Liquid, Liquid, Liquid and all that stuff. It's that thing of it's not that Shopify doesn't care in my eyes, it's just that to move a gigantic beast like Shopify, like it is now, is going to take so much time and steps. And it's that thing of you forget how high risk it is if you mess it up.

It's literally like my favorite analogy of this all is Shop Pay. When I look at people like my partner, I look at it from a tech point and think, oh, a big corporation has put an app, who's going to use that? Then my partner, who buys more stuff than I do, is like, Shop Pay is great. I can always just sign in and out. You're like, aha, I'm not the typical audience for this one. But it's always really good to see.

So I think my first biggest question is, what is Hydrogen compared to something like Gatsby and Next, as they're the other tools you would use to maybe build a custom storefront with Shopify?

00:12:52 - Josh Larson

That's a great question to unpack. I think there are a lot of differences. First, the intention of the frameworks, and then also the technical implementation.

So first, the intention of Hydrogen as a framework is very hyper opinionated to be a Shopify storefront web application. This is an area we're still actively exploring and trying to figure out. Okay, how can we make it even better, even more specific. But we want to make it as easy as possible to communicate with our storefront API and build dynamic, customized, personalized experiences for shoppers. Make it really easy for merchants and merchant developers to deploy to production, take it to production. That's a whole thing we haven't even touched on yet. You don't have to be a DevOps person anymore if you're hosting on Oxygen.

The intention of that is to make it as easy as possible to get going and create a great development and production experience.

I think under the hood, it's so interesting to watch the progress of these frameworks over the years, and forgive me if I get something wrong because it's been a while since I played with Gatsby.

00:13:49 - Josh Larson

I know Gatsby started out as more of a static site generator with some really cool abstractions for loading data. You kind of build a GraphQL API within a GraphQL API and be able to pull in things, and then at build time, it sucks all those in and makes them static, and that's really cool.

Then Next.js started out as a server rendered React framework. You had server rendered, and then a few years back we saw them lean into static first and incremental static regeneration. And that new concept, which is a really smart move because then you're leaning into static, but you don't throw all the server rendered stuff out the window. I'm sure it cuts down on costs for hosting as well, serving a static file versus having to server render every single thing.

I think when we look at Hydrogen, we kind of take the stance that dynamic server rendered is the answer for commerce applications. Specifically, we find that larger merchants and the merchants we've talked to, again, don't just show a product and allow you to add it to a cart. They're adding a bunch of personalizations, A/B tests, customer information. You need to be able to make really cool, advanced decisions about what products to show what users and drive them through a funnel and make it a great experience.

We found that a static generated site makes that really difficult. Certainly you can layer on a bunch of stuff and maybe do some cool edge stuff. I know Gatsby is starting to lean back into dynamic server rendering. I think they've called it [unclear], which is interesting to see the circle come back to server rendering again.

But this is our stance. Dynamic is the way to go. You can still do static things, right? Because maybe I have a marketing page that doesn't have any dynamic stuff on it. I can slap a cache control header and have it cached at the edge, and I don't need to spin up server cycles to render that.

But at its core, we want to lean into server. And I think also that's where our decision to do streaming server-side rendering and React Server Components, even as an experimental project, came into play for this, for Hydrogen.

00:15:41 - Christopher Burns

What you're saying is, wow, you can build with Next and you can build with Gatsby. What Hydrogen specifically is, is an opinionated React framework specifically for e-commerce and Shopify. If you tick those two boxes, then the opinions of Hydrogen will work well. And then it brings on to the next question. Where do you host this? Because I guess you don't host it on Vercel and Netlify.

00:16:07 - Josh Larson

Hosting is a big thing. This is something, because I've been heads down on Hydrogen for how many months now, I haven't been thinking about hosting and the complexities involved with hosting. But we are building a thing called Oxygen at Shopify, and Oxygen is our hosting platform for custom storefronts and Hydrogen storefronts.

We think it should be easy to go to production with a custom storefront. We touched on Liquid briefly as kind of the first thing Shopify offered. We've been hosting storefronts for a decade plus. They just happen to be Liquid storefronts, and we still are confident that most merchants are still going to use Liquid. It's a really cool, really easy way to just dive in and pick a theme, customize it. It's really, really powerful.

But there is a certain type of merchant who wants to take it a little bit further and go custom with Hydrogen. Hydrogen plus Oxygen is really cool. Oxygen is a V8 worker runtime, very similar to Cloudflare Workers, and it allows you to execute JavaScript and get HTML back.

00:17:00 - Josh Larson

But the real benefit is that we're running this in our data centers co-located with our databases. So when you're querying data from your storefront, it's right there next to it. You don't have to hop through all these network loops and have delays. You're looking at milliseconds for data queries.

00:17:17 - Anthony Campolo

And Oxygen is still kind of in the works.

00:17:19 - Josh Larson

It is still in the works. We don't have a hard release date yet for Hydrogen or for Oxygen for GA, but hopefully this year.

00:17:26 - Christopher Burns

We've quickly talked about where you're going to host it and the framework. I think it's really great to talk about the specifics of how Shopify is innovating towards the Jamstack. Jamstack is a very generic term for JavaScript these days, but why are you doing work on the framework level?

You've also hinted you're going to be potentially making the whole API experience better. Does this mean you're going to be building new React hook style API calls for Shopify? Because the reason I say that is because every time I've implemented Shopify, I've always used custom third-party hooks, or hooks that I've built myself, to manage the Shopify state, like checkout URL, take users to checkout URL, and all these other things. So is this something that you're looking at, like a more unified React library that will then sit on top of Hydrogen to communicate more with Shopify?

00:18:23 - Josh Larson

Yeah, that's absolutely our intention with Hydrogen. We've been kind of internally looking at Hydrogen as almost two distinct things. One is the framework, which we've spent time talking about up to this point. And then the other part is the set of components and hooks.

Right now it's React components. That doesn't preclude us from introducing a Vue Hydrogen flavor someday in the future, or Svelte. But that's exactly our intent, right? To make all these common use cases, Shopify specific use cases, really easy to pull in. You can pull in a Gatsby app if you really like Gatsby. You can use that or Next.js or anything and pull in the components that make building storefronts really easy with the Hydrogen SDK or whatever we end up calling this thing. But yeah, that's definitely our intent.

00:19:03 - Christopher Burns

What we're trying to say here is that while Hydrogen, Oxygen, the components, all of these things, if you look at it, it's really a pie in thirds. What Shopify is doing here is not saying only we're a hosting company. You're not just saying we're a new Netlify for Shopify. You're not only saying we're the data carrier between our custom storefront API and making a payment, but you're also saying we're a new framework.

You've basically taken the three aspects of very successful businesses at different sizes and said, for this specific use case of Shopify Plus e-commerce, we're going to handle the whole stack of JavaScript from the front all the way to the back.

00:19:45 - Josh Larson

Yeah, it's been important to remember that too as we're building things out. So our Hydrogen team is always thinking about the APIs that we offer and what we need to build in the framework. When we need to add something or discuss something, it keeps coming up like, oh, what are we building? We're building a hyper customized, opinionated thing for Shopify apps.

It's really easy to get distracted by the other choices that have been made in the Jamstack world for frameworks and more generic web apps. Your Vercels and your Netlifys are building a very generic thing where they have to support all these different use cases, but we don't have the burden of all of that. We're able to be constrained in our purpose, and I think that allows us to make decisions that fit that stack that you mentioned and make it really easy to get started.

00:20:27 - Christopher Burns

This is really exciting. I'm really excited for this. Say you work with a custom company and they go, Shopify is great. Everything but not search. I want to use Algolia. That's all. All totally possible, using Hydrogen and swapping out whatever you want with, say, a custom React library for different use cases.

00:20:47 - Josh Larson

Yeah, that's what we found, especially with larger merchants needing to build custom storefronts, is that they do want to use these third party integrations. Or maybe they've built their businesses around things like Algolia for search and, again, Contentful or Sanity for all their content management.

A big part of the story of building Hydrogen has been finding ways to be compatible with that and building a story around third-party integrations that is not painful. I think one of the first plugins we actually worked closely with was Sanity. Day one of dev preview, they already had a plugin ready to go. They've done a cool thing where they wrap around one of our primary hooks in Hydrogen called useShopQuery, where you pass a GraphQL query with some variables.

What they've done is they've hooked into that and grabbed data from developers or merchants' Sanity account, and there are essentially foreign IDs for Shopify products. Then they take that data and run a Shopify query to enrich that data set, and then they reshape the data to fit the needs of Hydrogen components.

00:21:39 - Josh Larson

And so if I'm using Sanity and I'm using Hydrogen, I can install this component. I have my data formatted a certain way, but then I can just augment all of my product data with the data that I've chosen to put into Sanity as well. So that's what we kind of see as the integration path. It's definitely an area we're still exploring.

00:21:56 - Christopher Burns

It's super exciting, and I think it's actually really beneficial that, as you spoke about, you said the specific word enrichment. The more I spend time on the internet, the more I realize not everything is cookie-cutter. You design something for a certain purpose, and then someone's going to want to use it for a completely different purpose that you've never thought of.

So it's all about how can we give the best use cases and be open to connect with others when necessary? One of the big things that I also wonder is whether there will be a more customized checkout experience with Hydrogen. Because this is actually something that I've noticed. If you've used headless checkout, while it's great, it'll always spit you out to the Shopify default checkout. That's not bad, but sometimes you may want a fully custom checkout.

00:22:43 - Josh Larson

That's a great question. The focus of Hydrogen has not yet been in the checkout area. It's more the first part, the add to cart area. I think that's an interesting area to explore. I know that we are really leaning into using the same checkout everywhere because you've got a really, really good optimized experience that's been battle tested at scale, but I'm sure there are areas we're exploring for customizations and stuff.

I'm not a good person to answer what exactly we're doing there, but I totally hear you. If you're customizing a full storefront, you want to customize the experience, so that includes checkout.

00:23:15 - Christopher Burns

And the biggest thing is, when you say headless, how headless is headless, right?

00:23:19 - Josh Larson

Yeah.

00:23:20 - Christopher Burns

Because that's another thing. At my own company that handles payments, we're looking at when we say we want to tackle headless payments, it's like, well, how headless is headless? Is that just the button that says click here to make a payment and then it spits you out to a defined checkout that's already defined? Or is that something completely custom where you say, we'll just handle all the logic, you put all of our components in however you want it to look?

These are really interesting questions that I have, but they're very specific questions. I've been in this area, I've seen the problems that it's facing, and I'm really excited for Hydrogen. So I'm sure Anthony's got some great questions lined up that are more generalized.

00:23:58 - Josh Larson

Sounds good.

00:23:59 - Anthony Campolo

Yeah. I was curious to get into the React Server Components. We have talked about this a little bit on the show, and it's something that is kind of a future-facing thing for most people. But you've been building on it.

According to your docs, you have a built-in layer of abstraction that provides stability on top of it. So I'd be curious to get a high-level description of what React Server Components are, and then how they're being used by Hydrogen, kind of how much of your own stuff you've built out versus how much you're using just the base library.

00:24:31 - Josh Larson

React Server Components were introduced in December 2020 as this experimental thing that the React core team was considering. As we started building out Hydrogen, we found ourselves in the same position that every other meta-framework has been in where they're like, okay, we can server render a page, but now we need to find a good way to load and fetch data, and then we need to hydrate that on the client for subsequent client single-page navigation.

We were faced with the option of, all right, we've got to invent our own get server props. Or you know, Remix has their loader functions. It felt kind of weird to have to do that when we knew Server Components was just around the corner.

What we ended up doing was building a version of that that worked for us, that unblocked us by taking the same patterns that Server Components lays out and integrating them into Hydrogen.

00:25:23 - Josh Larson

Specifically, what that means is that you have a clear boundary between server components, components that render on the server, and then client components, components that render on the client and have associated JavaScript files in the browser.

The way that we're using that in Hydrogen specifically is that we are really trying to emphasize fetching data on the server. We think that's going to be the way forward in the future. We think if you're fetching product data, but then also customer data and potentially business-sensitive data that you've stored in maybe metafields, you don't really want to do that on the client. You probably want to do that on the server, and you want to do that in a safe way. And so that's been our mission from day one, to do that in a server-friendly way. Server components really fit the bill for that.

So we have each page in Hydrogen as a server component, but then you can spin up additional server components. Those server components can render what React calls shared components, which are just component JS or other server components, or client components dot client dot JS.

00:26:21 - Josh Larson

This is definitely an open area of exploration that we are looking into. But I think what we've talked about a lot internally, and hopefully externally soon, is that we see a huge change coming in the way that React applications are built in the next several years with the combination of Server Components and React 18 streaming SSR and Suspense.

The way that modern SSR frameworks have been built has been really tightly coupled with route-based data loading. You see that in Next and in Remix, where your routes have a loader function of some sort. You fetch data, maybe fetch a few things after that, wait for all that data to load, and then you return the page. Or if you statically generate it like Gatsby, then it's really fast.

But if you're server rendering, you're kind of stuck on a waterfall of data requests to make all that stuff really render to the user. What we see happening in the future is for data fetching to be more co-located on a component by component basis, wrapped in React suspense boundaries.

00:27:20 - Josh Larson

And so you start streaming the response immediately with some skeleton fallbacks. You have to be careful about how you design those so it's not a really terrible user experience with 80 million spinning wheels loading in with your page. You have to do it in a smart way.

But then you're getting response to the user really quickly, and your data fetches are nested within the locations on the page where they're happening. I think that's kind of the biggest differentiator right now between Hydrogen and other frameworks, is that we're really leaning into this thing that we see as the future: Server Components.

As part of that, the biggest win with Server Components is the clear boundary between client and server. But I think the bigger delta, the bigger win, is actually with React 18 streaming SSR with Suspense.

00:28:02 - Christopher Burns

With Server Components, one of the things when it came out, the team who were building Hydrogen, if it was even being built at this point, was like, this is just what we needed. This is the golden piece that is missing.

00:28:14 - Josh Larson

Yeah. So they came out in December. We started building Hydrogen in April, so not even a year ago. We did mention, even in our company Slack, like, gosh, I just wish server components were ready.

Since that point, and we kind of built a modified version that fit our needs, we have been working with the React team to find out what's in store for this. Is this legit or have you realized after a year of experimenting that this is not the way forward? And it sounds for the most part that we still are confident that this is the way forward, and we're still trying to figure things out, like that data fetching thing I just mentioned.

There are implications for serializing that to the client. How do you do that properly? I think it comes back to, again, Hydrogen being a specific framework for commerce. We are able to solve a specific use case, whereas the React core team has to pull this giant, massive ecosystem into this modern new era.

00:29:02 - Josh Larson

Their jobs are much harder than ours because we can be super opinionated and we can provide things like data fetching. I mentioned useShopQuery before. That's kind of our abstraction around data fetching. So you pass it a query, we run the query on the server. You don't really need to care about how it runs. We just do it.

That allows us to have it implemented one way. And then if the React team comes out with a new thing they've discovered, oh, this is actually a better way or a smarter way to do data fetching, we can swap that implementation out. Even under a minor release of Hydrogen, developers and especially customers really won't know the difference.

00:29:35 - Christopher Burns

I guess the biggest question I have right now is, do you feel like you're living the future today every time you work on Hydrogen?

00:29:43 - Josh Larson

I do. Some days are painful, right? It's like working on the bleeding edge. You're going to bleed a lot and it's fun. But some days I'm like, gosh, I want to work on a really boring thing. Next I'm going to work on a really straightforward, server-rendered thing: PHP. I'm going to go back to WordPress.

But it is really fun to be kind of on the edge of stuff and to see a peek into the future.

00:30:03 - Christopher Burns

Yeah, I think it's such an interesting area. When React came out, it was like, oh, Create React App is the only thing, and that's just how it works. But now, the further we're going forward, it's like frameworks are being built, but it's not about React. React is just the thing that everybody uses now.

It's, you know, server-side render everything. Well, I statically do it in the middle. None of these things are bad. But I think the most important thing is the use cases, because a full server generated React app would be really overkill for a blog. But something that could change ever so slightly for every single user, and you need that speed, server-side rendering seems not the only choice, but the most interesting choice going into the future.

Because it's that full circle of, well, we tried doing everything static and then we just rehydrated everything anyway. So what was the point of doing everything static? We'll all go back to the server, and then we're at the same part where we'll be doing the same thing in ten years.

00:31:04 - Christopher Burns

I think my final question regarding this all is how open source is Hydrogen, and how you are looking to support the open source community with what Hydrogen is building?

00:31:17 - Josh Larson

It's open source and we try to do a lot of stuff in the open. Very few conversations actually happen in private as far as framework direction sort of stuff. So we've had a lot of amazing third party developers already contribute to Hydrogen and are very excited about contributing to it.

One thing we just talked about on the Hydrogen team this week is that living on the bleeding edge of server components, we're going to have issues with very popular third party libraries that people are going to come in and want to use. So part of our team's job is to collaborate with them, and that maybe literally means going into their repo and opening a PR and saying, here's how you can support this next generation of stuff.

Or even in a Hydrogen context, there's a fair amount of third party interaction that our team is going to have to do to make this really work well and make it a reality for people. But that's kind of exciting, too, because we're not just sitting isolated and we get to see what people are building and what they're using.

00:32:11 - Christopher Burns

Yeah, I just can't wait for the day where somebody will say, well, I'm going to use Hydrogen for not e-commerce, and I'm going to host it myself because it's going to happen, right?

00:32:20 - Josh Larson

Yeah.

00:32:21 - Anthony Campolo

Yeah. One other thing that I was curious to get into is that it looks like you don't have a REST API for storefronts, as GraphQL is the default. So that was kind of interesting. Can you talk about why that is and what kind of the downstream effects of that are?

00:32:38 - Josh Larson

So that decision certainly predates me being at Shopify. I've been here a little over a year, but if I had to guess, I think that GraphQL lets us make really specific queries. I think the key of GraphQL is requesting exactly what you need instead of requesting the whole firehose of data.

That's sometimes easier said than done. We struggle with this within Hydrogen right now. We want to provide these components that work out of the box, like a product page where you can select variants and see the image of the product you selected, but that requires you to request a certain amount of data. And so all of a sudden, we've gone from GraphQL being this really specific API to maybe potentially over-fetching data for users who didn't necessarily need all the data that we've added as part of the component that they're using.

So I think there are interesting challenges, but I think Shopify has really leaned into GraphQL. They've adopted it quite a while ago, and we have a really cool team working on our GraphQL APIs and improving them.

00:33:34 - Josh Larson

So I don't know what the specific implications of not having a REST API are, but I think GraphQL has worked pretty well for us.

00:33:40 - Christopher Burns

I would say when I've used Shopify, GraphQL has never actually been a problem. I've always enjoyed using it. I think the only things that sometimes are issues are that, as we know, Shopify is a ten-year-old product. There's things that get deprecated and the new version comes out, and sometimes some of the wording for the new things are like, this is V2.

You know what I mean? Price V2, my favorite compare at price V2. I'm sitting there going, which one's going to tell me this is on offer? And then it's the other big questions like, okay, so what's the discounted price? What's the RRP price and what's the price right now? Can't you just put which one's the RRP? It's like, this is the RRP, RFP price. This is what we recommend.

It's all these things. It's not that Shopify doesn't want to do these things. Obviously I'm speaking from the outside, but it's because it's multilingual. It's multi-country. It's this giant behemoth that has so much work to it that these nuances are big changes.

00:34:42 - Christopher Burns

As you can see, I've enjoyed every time that I've used Shopify. But yeah, I'm really excited to see what comes.

00:34:47 - Josh Larson

That's awesome. It's great to hear, and I totally feel you on the price V2 thing too. That's a paper cut.

It's actually funny because our CEO, Toby, instigated a lot of this work when he sat down and took a week to build his original Snow Devil shop, which is how he started Shopify. He wanted to build and sell snowboards online, and he rebuilt it in modern tech. And he found all these pain points that you mentioned with the GraphQL versioning and stuff.

So our team has really spent a lot of time improving not only building Hydrogen, but then building and improving the storefront API. Those V2 things are going away. We've actually contributed some stuff upstream to the Ruby GraphQL thing to be able to properly handle old versions of objects. And we're improving, and it's so fun. When you take a look at your own stuff from the outside, you have new opinions on how it should be done.

00:35:36 - Christopher Burns

Where can the users find you? Where can they find Hydrogen? Are you looking for anything specific? Do you have jobs going? This is the space to plug yourself and Shopify as much as possible.

00:35:47 - Josh Larson

Man, yeah, this is great. I'm totally unprepared here. I am on Twitter at @jplhomer.

You can learn more about Shopify. Well, let's start with Hydrogen. Hydrogen has a really neat landing page at Hydrogen. You can also just go to Shopify and click through to custom storefronts where there's all our documentation for Hydrogen. And of course there's a GitHub repo which is open source.

Shopify is always hiring. We're building some really cool things again with Oxygen and Hydrogen and custom storefronts. We could use help if this is something that interests you. So definitely come join the team and help us out.

00:36:24 - Anthony Campolo

Awesome. Thanks for being here with us and telling us about Hydrogen. Sounds like a really interesting framework that's doing a lot of cutting edge stuff, so I'll definitely be interested in poking around and building some stuff out with it myself.

00:36:36 - Josh Larson

Cool. Thank you so much for having me. It was great chatting.

00:37:08 - Christopher Burns

Was that all okay?

00:37:10 - Josh Larson

That's great.

00:37:11 - Christopher Burns

Great. I hope I wasn't too like, this is awful.

00:37:15 - Josh Larson

No.

00:37:16 - Christopher Burns

I'm very passionate about this area. I really enjoyed working on a storefront as a side project.