The Changelog: Software Development, Open Source - Shopify's vision for the future of commerce (Interview)

Episode Date: November 19, 2021

Today we're joined by Ilya Grigorik to talk about Shopify's developer preview release of Hydrogen and the preview release of Oxygen which is in early access preview with select merchants on Shopify. Hydrogen is their React framework for dynamic, contextual, and personalized e-commerce. And Oxygen is Shopify's hosted V8 JavaScript worker runtime that leverages all of their platform with the hope of scaling millions of storefronts. We cover what developers can expect from the Hydrogen framework, Shopify's big bet on React Server Components, the future of Shopify at scale with Hydrogen powered by Oxygen, and a world where merchants never have to think about the complexities of scaling infrastructure.

All right, welcome back. This is the Change Law. We feature the hackers, the leaders, and the innovators of the software world. Today, we're joined again by Ilya Gorik. We're talking about Shopify's developer preview release of Hydrogen and also Oxygen. Hydrogen is their new React framework for dynamic, contextual, and personalized e-commerce. And Oxygen is Shopify's hosted V8 JavaScript worker runtime that leverages all their platform with the hope of scaling millions of storefronts. We cover what devs can expect from the Hydrogen framework, Shopify's big

bet on React and React server components, the future of Shopify at scale with Hydrogen powered by Oxygen, and a world where merchants never have to think about scaling infrastructure again. Thank you. Feature Flags, Powered by LaunchDarkly. Get a demo at launchdarkly.com. This episode is brought to you by our friends at Fly. Fly lets you deploy your apps and databases close to your users in minutes. You can run your Ruby, Go, Node, Deno, Python, or Elixir app and databases all over the world. No ops required. Fly's vision is that all apps should run close to their users. They have generous free tiers for most services, so you can easily prove to yourself and your team

that the Fly platform has everything you need to run your app globally. Learn more at fly.io slash changelog and check out the speed run and their excellent docs. Again, fly.io slash changelog or check the show notes for links. It's good to have you back. We've been obviously acquaintances and friends over the years, having done many shows together. Talked about a lot of stuff you've done, post-rank, speedy, performance on the web, your career at Google, now at Shopify, and just excited. I reached out to you on LinkedIn when you made that move, and you said, well, we'll talk later.

And so I think now is later because there was this big release, Hydrogen is out there, Oxygen to come, a lot of fun stuff happening. And I guess you're combining a lot of the efforts, which is like performance, but also dev tool related in this release and what's going on. But one, just good to catch up with you. So welcome back to the changelog. Thank you. Yeah. Thanks for having me back. It's always fun. Yeah. And even more, we're big fans of Shopify. We have our own, I'll plug our merch store. If you don't mind, Jerry, can I plug our merch store? I don't mind. Elliot, do you mind? Please.

It's easy. It's merch.changelog.com. It is powered by Shopify. I think we use the kit. I forget what it's called. Whatever kit, it's like the basic way, the CLI version of like deploying our theme. That's how we do it. We deploy our theme to Shopify via the CLI. Super easy. We have it stored in Git, of course, on GitHub, but then we deploy it via the CLI and I love it. So it makes managing our store so much easier, but big fans of Shopify, big fans of you.

So catch us up. You moved from Google to Shopify. What made that move make sense for you? Why did you make that move? What's so big about Shopify? First, I just want to say that I spent a decade or so at Google working on a number of different projects. And it's an amazing company with lots of smart people and amazing technical playground. So there's no shortage of opportunities and really interesting projects.

But at the same time, I was always really curious about commerce. I've worked with commerce, large commerce sites, helped many improve performance, but always had this inkling towards, hey, it'd be really fun to get really hands-on and work in a capital P platform for commerce.

And Shopify is an obvious place today. It's emerged as a really big player and enabling millions of merchants to build their online presence. So it felt like a great opportunity and really interesting and familiar technology stack for me. Of course, I think one of the first shows that we did back in 2011 was a Ruby server that I was developing, my team was developing, called Goliath. So I was working on streaming and async HTTP server for Ruby. And of course, Shopify is a Ruby and Rails shop

through and through. So it's just an opportunity to come back to the Ruby tried that was also very fun. I found I rediscovered a lot of long-lost friends. It's like, hey, remember we hang out at the, or we hang out at this event back in, you know, 2008, that combination of all of those factors and the fact that commerce is only growing in relevance and importance. I think this is one of the themes that maybe we'll both touch on today. COVID was an accelerator for commerce. It shifted a lot of commerce

online. It became much more important. There are many merchants who have thought about, hey, I should get online. And then all of a sudden, they had to overnight. Shopify was there to help. I think that we did a really good job on that front. And yeah, so combination of all these factors enticed me to jump aboard the Shopify ship. And I've definitely not regretted it. I've appreciated the scope of opportunity coming in, but seeing how the factory operates from the inside only gave me more appetite

for the space because Shopify is not just a storefront builder. I think a naive view of Shopify is it's a place where you get an online store and sell stuff, but it's so much more because the superpower of Shopify is that it integrates all of the pain of doing commerce, which is very, very deep.

It's questions like, how do I do shipping? How do I do credit card billing? If I have a return, how do I handle that? How do I handle my customer database? And there's a million of these little things, as you guys know, because you're running the store, that if you don't have a system that actually works well together, you'll end up spending 80% of your time on that minutiae instead of actually doing the thing that you're supposed to be doing, which is doing your podcast or selling your merchandise.

Yeah. I mean, I love that we all have Ruby Roots, too, and that it's a Rails app. I mean, it's a Ruby app now. We've talked about the big rewrite in a past show. We'll link it up in the shows. But even the R&D around that front, like what does it take to make the application performant for all the necessary reasons?

I think you're absolutely right. I think the one thing that has been holding or in any way holding Shopify back would be the integration of developers. And I think the React framework on the storefront is a phenomenal move. ThemeKit is great, but it's got its limitations. Even how do you build locally and all these fun things. How do you give a developer a playground that is commerce related

is the question that you've solved here. And I think that once you solve that, it's just like floodgates. I'm expecting floodgates to open up because this is going to be a lot of fun. Yeah, I think we still have quite a bit of work, if we're honest, to do to really transition into a capital P platform. But I think that's where you're seeing the company head. And that's what has me really excited. And just to double click on that briefly, I think the superpower of Shopify is the fact that it actually appeals to non-developers. This is the no-code commerce.

So if you're familiar with the foundational myth, but it's not a myth of Shopify. Every tech company has this myth. And the Shopify lore is Toby, who's our founder, at the time he was also a Rails core contributor. He was working in Rails, moves to canada he's stuck in an auto winter and he has an idea for hey i'm going to open an online snowboard store and this is like early 2000s he's a developer so he starts coding and he takes a year to build this thing

and he launches his snowboard store and he does have like you know a couple of sales and all the rest and then comes to a realization that you know maybe the value prop here is not the fact that i'm selling the snowboards but in the technology that i built to power the store because unless some other merchant is also as technically proficient as i am they have no chance yeah in this space right and then that becomes the foundation of shopify and you can see this kind of woven through the product through and through where Shopify historically is optimized for you're a non-technical person who wants to start an online store.

Let's make it as simple as possible. In a couple of clicks, you type in your products, you click publish, you have a website, right? You should not have to reason through all the complexity of that. And that's the kind of no-code environment. And I think this is why Shopify has millions of merchants on the platform. Because we make it approachable and you don't have to be a technical expert.

We have a local friend we have here. I live in a small town in Texas. A small town outside of a big town. We live in Houston technically, but it's a small town outside of that called Tomball. You know about that, Jared? Tomball. Tomball. And there's a street called Main Street in Tomball, like any small town might have. And that Main Street has a store called Kids Anthem. KidsAnthem.com is powered by Shopify. It's friends of ours. We built that from a theme. We didn't build the whole store front.

We didn't do all the technical bits behind it. But this is a small next door, literally next door neighbor friend of ours. We help get online. Her store is a large percentage of her revenue. Small town shop in Tomball. Yep. So I think that's exactly right. And just to contrast that, right, like this is early 2000s.

And if you wanted to get on commerce or if you want to do commerce at the time, you would be looking at an RFP with hundreds of thousands of dollars to hire an agency to do an integration, and then you have to like navigate through banks. It's just inaccessible, right? And that's the problem that Toby wanted to solve. And I think we've done a pretty good job of it. And to your point, now, you can start with this no code experience, and then we have the ecosystem of apps and themes where you can start kind of flexing and customizing, right? So you can bring in a custom look, you can hire a developer and pay them

for a couple of hours of work to really make it your own without having to build this whole thing from ground up. And I think this is where Shopify's really scaled and succeeded over the last, I guess, 15 years. And now we've built all this technology. We've built this platform. We run millions of merchants. And we're looking at this thing and saying, look, it's kind of like magic, right? Like our merchants don't have to think about scale or like running Kubernetes clusters and CDNs and all those things. We handle that for them. But there is a subset of merchants and a subset of developers,

folks like yourself, who want to have a bit more control, right? They want to peel back the curtain and like tweak it. So it could be used Shopify hosting infrastructure to run our own custom stack. It's not a crazy question, right? Historically, the answer has been no, you had to write liquid code. You can do a lot of things in liquid, but maybe it's not the right tool for every team under the sun. So now, I think we're going through this exercise of saying, how can we bring out some of the components that power Shopify and make them accessible to developers in a composable way? So oxygen is one

of those pieces. Hydrogen is the framework that we're going to talk about, the React framework. And I think we're still at the beginning of this journey. So, you know, you said, as you said, opening the floodgates. I think that's exactly right. Absolutely. And we still have a lot of work to do. Well, should we dive right into hydrogen or you should give us some oxygen first? Where should we start?

Let's see. Maybe to start, we can talk a little bit about headless commerce. And because oftentimes when folks approach, you will likely discover hydrogen and oxygen because someone, maybe a product manager or a customer came to you as a developer and said, hey, I'm like, I keep hearing about headless. I need one of those. Can you build me one of those? So what is that, right? And it's a term that I love to beat up on

because I think it's unfortunately very much outdated and we just need to all agree to deprecate. So if you allow me a little tour down the memory lane here. Please, yeah. But where did headless come from? I think the inception and why it stuck so vividly in everyone's mind is around 2011, 2013. This is when the web is going through this transition

from desktop only to desktop and mobile. And that was very painful, as you guys remember. We all have memories of trying to browse the web on our little mobile screens and pinch zooming and trying to tap on a link that is way too small and you're missing it. And it's just frustrating. It kind of dawned on everyone that the technology of the past, you know, the WAP protocol and all the rest, like, is not suitable enough. Like, the mobile web needs to be more capable, but you can't just cram desktop web. So now, where you had this tight coupling between the back-end and the front-end, and the front-end was synonymous desktop web, you needed to separate

those out. You needed a different mobile experience. You probably also wanted to explore a different mobile app experience, and you had a desktop experience. So the whole meme of headless is about, let's chop off the head, which is the desktop web, right? And instead, focus on APIs. Like if we have a robust API that exposes all of our content, databases, what have you,

business logic, then we can build these different experiences so it's kind of an unfortunate term because as with any definition by negation right like headless i'm headless now it's like oh great you have an api you have a headless storefront the point is not to be headless the point is to have many different modalities in which you can sell right it's the desktop web it's mobile web it's a mobile app. Nowadays, it's like VR apps, AR apps. You're selling on Facebook and Instagram and TikTok. There's all of these channels that you need to be present as a merchant to really drive commerce. So it's not headless, it's API first. And Shopify, of course, has been a provider of APIs since the very beginning.

We were one of the early adopters of GraphQL, actually. A fun anecdote, I was just looking at one of our API dashboards last week, and it's always fun to see the growth up and to the right and just like how is the slope changing over time. And recently we saw a peak of 1,000 QPS. So that gives you a sense for scale that Shopify operates. And this is purely API traffic. MARK MANDELMANN- What's QPS?

JOHN MUELLER CHAMPENOIS- Queries per second. Coming into the GraphQL API. So Shopify is actually one of the largest, as far as I'm aware, public GraphQL providers. I think there are other apps like Facebook and others that operate in even larger scale in their private use case. But as a public API provider, I think Shopify is one of the largest providers, which is kind of a little known fact.

And we have a really smart set of folks working on GraphQL infrastructure at Shopify. So Shopify is headless in that sense. And I think this is one of the misconceptions in the market. It's like, oh, Shopify is the thing I go to build my online store. Not quite. We also have the GraphQL API and lots of merchants have built really amazing mobile and other

experiences on top of that. That may be like part one. The second part is and maybe a better replacement term that's now being used in the e-commerce industry is this notion of composable commerce, which is which is hey there's lots of different tools out there like there's some really good tax applications and there's some really good shipping applications and inventory management and asset management they all provide api's why don't we just use or the best of the breed for all of them stitch them together and build the best commerce experience which sounds really nice, right?

And Shopify certainly plays in that space. Like many of our more advanced merchants use Shopify for a set of workflows, but then extend their capabilities via other tools by providing integrations with APIs or just custom code integrations and all the rest. The challenge though, as anyone that has built a distributed system will know,

is just the fact that you have the best car parts or you bought the best car parts doesn't mean you have a good race car. You really need to invest into like a really solid pit crew and engineering crew to build out a system that works. This is the hard part of integration in all of these systems

and actually keeping it up and running. So this is where I think Shopify excels or historically excelled because we integrate a lot of this pain, so you don't have to think about it. But if you want to go to this composable route, now you have a set of hard choices. Let's say you wanted to pick a different front-end framework, so you don't want to use Liquid.

Sure, you can take React, a Vue, or whatever other flavor, doesn't matter because you just have GraphQL, and you can build that out. But now you're not querying data locally from the same data centers as Shopify. So now you have to think about the latency of your data requests. And maybe you can patch that with pre-building all of your pages

product pages right so this is kind of a statically generated route okay that works then your product manager comes to you and says but actually i have you know a thousand or a couple of thousand products and each one of them has n number of variants so your build tree just exploded in complexity and of course i also also want to run a b tests on top of that and did i mention that i want personalization oh and make sure that you architect in such a way that i can do really effective dynamic search and before you know it you're kind of sitting there scratching your head trying to figure out how to make sense of all of the soup and this is where we we saw a gap in the existing frameworks and tools and why we thought hey first let's open up some of the soup. And this is where we saw a gap in the existing frameworks and tools

and why we thought, hey, first, let's open up some of the technology that we built at Shopify, which is the Oxygen runtime. So Oxygen is the V8, so it's a worker runtime. Similar, if folks are familiar with Cloudflare workers or even AWS Lambda,

it's a JavaScript worker runtime, more similar to Cloudflare than others because we adopted web APIs. And it runs on Shopify infrastructure. It's powered by V8 isolates. And effectively, you just throw it. It's a HTTP function, right? It accepts an HTTP request. It runs your JavaScript code. It spits out an HTTP response. That's basically the entirety of its signature. But it allows us to run React code on the server or any framework, right? So if you want to write your kind of isomorphic JavaScript

where you're using React on the server in a client, you can do that. You can just throw it over the wall to Shopify and we'll run it. And most importantly, we can run it without you having to worry about how is it going to scale. One of the nice properties of Shopify is a fully

hosted platform. So if you run your store, you don't have to think about tomorrow, I'm going to have a big campaign on Instagram. And do I need to provision more servers to handle that spike, like we just absorb that traffic, we see enough of it. And the platform is flexible enough for for us to handle that for you. So in the same way, our hope is that you can just throw your JavaScript code over the wall, the server-side code, and we'll run it on top of our platform.

And this is a game that we've been playing already for over a decade, so we have a lot of operational knowledge. So it's not like this is an entirely new muscle for us. But what is new is the fact that we're running the V8 isolates, right? They're wrapped in kind of go processes and all the rest. So there's a set of new infrastructure being built out on that side. But otherwise, this is something we're very familiar with. And further, because we're specialized in commerce, we have commerce specific logic. So things like bot protection, like turns out if you really dig into commerce and you have flash sales,

there's an entire ecosystem of malicious actors that I didn't even know exists. Like bots that try to drain your inventory. If you have a really coveted sneaker drop, which is a big thing, believe it or not, you get tidal waves of bot traffic trying to drain your inventory the moment you launch your sale. And you have to build a lot of smarts

to figure out how do you protect your inventory from those folks, right? Such that they don't end up on a resale market somewhere else. Wow. Oh, so their MO is to buy all your inventory and resell it. Yeah, exactly. It's a very clear arbitrage play, right? It's like there's a coveted limited release, maybe a hundred or something or a

thousand and you want to buy up as much of it as possible because there's people are willing to pay big bucks for you know a pair of well-known sneakers that's right it's like a ticket master and ticket sales for a concert same concept like try getting you know tickets you got to be there yep the moment it opens up and even then you're lucky if you get the ticket. If it's like a coveted concert, for example, they sell out pretty quickly in minutes. And that's nothing a merchant should have to... I shouldn't have to operate a sneaker store.

And my focus should be on the coveted sneaker and my customer base and the loyalty of that customer base, not the bot network that's trying to attack my inventory. Exactly. But the bot network's actually purchasing your inventory, right? Yeah. Yes. So you sell out immediately at the price that you named.

I'm not seeing what the downside is for the merchant here, right? Well, your customers are upset. Yeah. No, the bot is your customer at that point. Yes, except that you actually have your fan base. Jared's the bot writer, by the way, Ilya. That's why he's the advocate for the bot, because he's the bot writer. Yeah, yeah. I think it is a good point, though, right? Like, what's the loss for the merchants? You made the sale. Okay, good. But

you have your community. And like the whole value of why does this thing have value is because you have community that believes and wants the thing that you're about to sell, right? So if they're all lining up in a queue to buy one of these things, and they'll wake up at ungodly hours to just have a chance at it, just as Adam said. They'd like to have a chance at this, right? If they lose at this game every single time, they'll lose faith in your brand, they'll lose faith in the whole thing thing and they'll move on to some other product. So it is important that it gets into the right hands. I guess maybe to make the game fair, the purchasing game,

you're making the purchasing game fair. Yeah. Right? Like if you're a bot that's trying to play a majority role in what should be an equal play, then we're going to, I assume, throttle you based upon some sort

of knowledge or signature of this is a bot network based upon its traffic type. Yeah. And that's actually another good point, which is, let's say you are a solo tech entrepreneur that is willing to roll up your sleeves and say, like, look, I got this, right? Like, I know how to write WAF rules. The problem is, this is a continuous cat and mouse game, right? As with anything security related. And you actually benefit from scale.

You actually benefit from working with thousands and millions of merchants and being able to observe the large traffic to build better signatures, continuously evolve them. And there are teams at Shopify that are dedicated full-time to do this. Shopify is not the only company, as you said. Ticketmasters and others have the same problem. And it's annoying that we have to fight it, but it would be even more annoying if you as a merchant had to now think about that next time you have your sale.

Well, what you're describing really is like this technical challenge that if we can remove, abstract away, to use a technical term that we often hear, if we can extract away the technical bits that is the hard part that you could do at scale with dedicated engineering teams, et cetera, for merchants at large is Shopify global at this point. I mean,

I know we're here in the U S is it global commerce? I know in a lot of ways it is, but I'd imagine if you take that pain away for merchants at large globally, then you make the friction to get into the game of like... Selling shoes. Transferring value to little customers, then it gets a lot easier. Yeah, so certainly the scope

for all the work that we do is global. We are globally distributed in terms of our infrastructure. We have clients and servers across the globe. So that's certainly true. I think it is also true that there's still a significant portion of our merchants that are English speaking countries, but increasingly,

it's becoming much more distributed. And I think you'll see Shopify investing into other markets as well, kind of in a big way. International selling is its own domain of complexity. And if you're a merchant that needs to work in multiple geographies like that that's its own complex world of functionality that you need some of which Shopify has there's still lots more to be done but maybe just to come back to the hydrogen and oxygen bits right so I hinted at one thing which is once you go into this world of composable commerce and as a developer there's a lot of complexity in how do I connect all the services together, one, and two, how do I take it to production? So Oxygen is our answer to how do you take it to production because hopefully we'll just give you a platform

where you just throw the code over and we just take care of a host of things that you don't have to think about, right? In the same way that you use Heroku and you don't have to worry about like, is my dyno running? In the same way, we'll take care of scaling this, putting a CDN in front,

doing all the bot protection that we talked about and all the rest. The other bit is the tools to actually build great commerce experiences. Our experience of working with merchants at scale, large merchants and merchants with sophisticated needs that are actually looking to hire developers is that they're not

building static commerce frontends. I think you can definitely build really high performance, really nice statically deployed commerce experiences assuming you're a certain size of a merchant or maybe it's like catalog size or you have a fixed set of products.

But once you move out the complexity curve into larger catalogs and you want to do things like A-B testing, personalization, contextual pricing, multiple geographies, and all of these things that a lot of the larger merchants have to battle with, the tools kind of fail you today. They don't give you all

the right batteries included things, and you have to reinvent that wheel time and time again. So our hypothesis, and all of our data backs this up, is commerce is dynamic. And if you buy that, I think you need to start with really fast server-side rendering as a core foundation on which everything else is built. So instead of starting with, I'm going to build my site and push it to the edge, and then I'm going to add layers of dynamic capabilities like A-B testing and all the rest.

Our bet is actually the opposite, which is you have to start with really fast server-side rendering. And then, of course, you add all the edge capabilities. Like there's a set of pages on your store that can be cached for a long period of time. Maybe it's the marketing pages. Like, great, serve it off the edge, right? Maybe even certain products are mostly static and you can

cashless at the edge like we have the tools for that you know cash control headers and all of these other things we can do that at scale but to really power dynamic commerce with large catalogs you need to collocate data and rendering which is one of our superpowers so when you deploy to your storefront to oxygen you get the the runtime, but you also get the Shopify database or your database, your storefront database co located right alongside, right. So when you're making those queries to resolve your GraphQL and in other requests, they should be returning within milliseconds, as opposed to having to traverse

the public cloud to get to hit the storefront API and get that response. And that really stacks up, right? So we believe that, A, yes, it is harder in many ways to deliver high performance dynamic commerce. But if you have the right infrastructure and you're running co-located data and rendering, you can go really far. And that's how Shopify is built.

What's up, friends? This episode is brought to you by our friends at Retool, the low-code platform for developers to build internal tools. Some of the best teams out there trust Retool. Brex, Coinbase, Plaid, DoorDash, LegalGenius, Amazon, Allbirds, Peloton, and so many more. The developers at these teams trust Retool as a platform to build their internal tools, and that means you can too. It's free to try, so head to retool.com slash changelog.

Again, retool.com slash changelog. Again, retool.com slash changelog. so ilia this sounds really cool how you're talking about co-locating the data and the edge functions one of the things that i keep saying over and over again i spoke with evan weaver from fauna on this generalizing that problem of we have our functions running at these edge cdns and yet our data is still is not co-located. That seems like a problem that lots of people are working on. It sounds like with Oxygen, at least in the context of your Shopify, you all are solving that for everybody. Now, generic solutions for your random web apps is not out there, but in the case of Shopify, you're co-locating that and making that server-side really fast. I think the best way to think about Oxygen

is it's a function-as-a-service runtime that allows you to bring custom JavaScript code, which will execute on Shopify platform with the benefit of having your commerce data being co-located, which just allows you to build better experiences. And that runs on top of our Shopify infrastructure, which is powered by Google Cloud.

In front of that, we also have the CDN, the Edge CDN, and that has its own set of function runtimes. You can actually think of it as onion layers. There's a set of requests that you really want to render being collocated with the data. And there may be a set of maybe routing decisions or maybe even some simple EBT testing optimizations that you can do or test, rather, that

can run directly at the edge. I think this is one of the areas that are still being actively explored by the community. We saw some really interesting work done by Next. We're thinking about it with Hydrogen as well, which is when you're building your page, or when you're building your website, like there's some set of pages that can run

at different tiers in the network. At least that's how my mental model is. And how do you designate them to run in those locations? Right, so you could say, maybe for this particular page, I don't actually need any data fetch. Or if I do, I'll cache it at the edge. I'll make that request once.

I'll pay the cost once. And I'll cache it for a long period of time and revalidate it asynchronously. For some other type of requests, like where you're actually personalizing, let's say, prices for your customer because they signed in, they have a loyalty program, and they have a stacked set of discounts, that really needs to traverse deeper

into your network path or into your topology, if you will, to hit that other endpoint, which is co-located with data and service a fast response. Pretty cool stuff. So server-side rendering, let's get into the hydrogen side. So this is a React framework. So maybe let's just start with React and we'll branch out from there because you're placing some bets on this. SSR is one of your bets you're placing. You also are selecting React, which does that lock out a

subset of developers? Of course, React is a large front-end ecosystem, but you do have people who love Vue, they love Svelte, they love other things. Are they able to use Hydrogen or is this just for React folk? Good question. So we started with React svelte they love other things are they able to use hydrogen or is this just for react folk good question so we started with react because we asked our merchants we talked to lots of merchants for what are their needs what are they hearing what are they asking and the message was pretty

loud and clear and not surprising i think to anyone listening to this podcast which is react is a very large and vibrant ecosystem, and just simple access to developers, number of components, and all the rest. So they asked us to build something that helps them be more productive with React. So that's pragmatically where we started. At the end of the day, the goal of Shopify is not to build web frameworks.

We'd like to build a really good one to empower developers to build great commerce experiences, but ultimately our goal is to help merchants sell, right? So we're certainly thinking about how do we build all of these technologies in a way that empowers developers of all flavors, regardless of what your technology choices are, to build experiences that they like.

As we're building the React components for Shopify, we're thinking about how can we abstract them as web components and make them reusable across the system? Now, is that true today? No, it's not because we took the short path, but we're already building. If you look at how the code is structured and how it's laid out, you can see how we can make it modular such that even if you wanted to use a different, for example, React framework, let's say you're using Next, could you bring some of the hydrogen components?

Hydrogen components are Shopify built, Shopify optimized commerce components. At the end of the day, we're building with a core assumption that you're building on top of Shopify and on top of Shopify data model. That allows us to specialize and offer an opinionated

set of components. If you want to use that in another React framework, you should be able to do so. I think we still have some work to do there, and we'll get there based on demand and folks willing to contribute. But all that to say, I don't think we have a strong bet on the framework. Like, what's the right choice? We're taking a pragmatic choice, which is is this is what our merchants have asked. And when we looked

at the available set of tools in the React ecosystem, we felt like the existing crop of frameworks, and particularly ones for commerce, don't solve the right problems, or maybe don't stack the right decisions to enable this dynamic commerce experience that we've been talking about. There's a host of really good tools

for statically generated pages, but if you really want to build a fast server-side rendered React-powered experience, you have to hire some really smart people to make that work. And that gets very expensive very quickly. And so most teams fail. They end up with subpar experiences, and we thought we could help. So this is why we entered into the space and said,

it's not like we've invented server-side streaming, right? Right. I think I was with you guys on this show 10 years ago talking about streaming in HTTP servers. So this is not new technology, but it's a new stack. It's a different stack. It's a different set of choices, right? So now the question is,

well, I do want to use React on the server and client. How do I do that while still delivering really fast server-side streaming solution that is not blocking on data requests, such that I can enable the clients to quickly render at least like a visual shell of the page, provide some like loading indicators and speak to that user experience aspect of speed, not just the technical metric of speed, right?

Like, did you get the fast time to first byte? Yeah. I can imagine us being two years down the road, having you back on, Ilya. So we're at the opening gates of a new thing for you. You put six months into this. You work closely with the React core team. So you've had very knowledgeable people involved with this project on how React works.

But I can just imagine like to Jared's questions, like, you know, why did you choose React over Vue, Svelte? And does it lock out other frameworks? I can imagine this at the beginning. And like any beginnings, you start from somewhere. I think that's exactly right. We took a pragmatic choice. So if you look at Oxygen, as I said, it's a thing that accepts an HTTP

request and spits out an HTTP response. It doesn't matter what JavaScript code runs inside. So any server-side JavaScript is fair game. On top of that, we have GraphQL, which is framework agnostic, of course. And now it's a question of how do you make the right decisions,

architecture decisions on the server of how you compose the response such that you don't end up blocking the response for too long, right? So let's say you need to fetch product data, query some product description data, maybe figure out card discounts. Can you do those things in parallel

as opposed to sequentially and blocking and stream that such that user has a good user experience so like that's a set of choices that you have to make and that's a problem that we're solving with with hydrogen you mentioned next js did you consider a similar approach versus all server-side rendering but kind of a hybrid where they have some pre-rendering they also have some server-side rendering. You mentioned, or is it just caching is your answer to all pre-rendered pages? It's like you've got a marketing page

or your about page, instead of pre-rendering it, just cache it. Yeah, we actually work pretty closely with the next team. They're also innovating and pushing in boundary and React server components. So React server components, it's this new hot thing

that the React core team dropped as a Christmas gift to the community last year. Right? And everyone got super excited because it's this RFC and it asks answers the perennial question of how do we actually separate client and server concerns? Can we create a convention around data loading patterns? Because right now every React framework has to figure out how do you do data loading, right? You know, get server-side props versus something else. Like you have to learn a new dialect every time you pick this up.

React Server Components tries to answer that. And further, it adds a set of new, or opens doors to a set of new possibilities. Things like, it wasn't possible to do component-level updates before. So if you've rendered the page, right, and the user is interacting with the page and you want to reload just a subtree, you can hack that via various ways. But there is no well-defined convention for how the framework itself could do that.

React Server Component answers that. It also, by separating, creating this boundary between client and server allows us to build better and more optimized bundles. One of the pitfalls, pardon the tangent here, of isomorphic client-server JavaScript is ultimately we're building these React applications to run in a browser, right? So there's a set of assumptions about browser capabilities and browser APIs being available. You bring that onto the server and you go, well, it's not quite like the browser right these apis are not available and now i need to figure out if i only run this code do i export these exports to clients as well like it becomes really muddy really quickly and maybe if you're super

judicious you can navigate through that forest but it's a very challenging problem rsc reacts our component defines those boundaries and at least on on paper it promises to solve many of those things and it's still under active development propify has been one of the early adopters we saw it we played around with it kind of tried to rebuild our own applications with that pattern and we felt like it felt nicer than what we were using before because similar to any other framework we were inventing our own data loading strategy. And then we swapped it out for our CM. It's new, so there's still friction

for most React developers because, well, it's a new shape of API. But you kind of get these second-order effects where it just feels more intuitive. It's easier to grok. So even though it takes a little bit of RAM time for someone new, they see the file name and it says.server and it kind of just clicks. It's like, oh, you know, I can infer

what that means. So we have the benefit at Shopify of starting anew. We're not a framework with an existing install base of thousands of apps. We don't have to move them over into this new world, which is one of the challenges with the React server components, suspense and all the rest. If you have an existing application, a lot of these things are not easy to adopt because they change how you have to think about data loading, different state transitions and all the rest. For better or for worse, we're starting from scratch. So we're willing to take some opinionated and future looking bets because we have the luxury of not breaking anything yet.

Yet. You have the luxury for now. Exactly. And this week, this is maybe a good transition to it. So what did we launch this week? This week, we launched the Hydrogen Developer Preview, which is, we're not claiming it as production quality code. In fact, we wouldn't encourage you to write production code. You could. Nothing stops you, of course. But we wouldn't encourage that

because we want to use the period of the next couple of months to really iterate on the APIs based on feedback from real developers and probably break things. Right now is the time to dramatically change in backwards incompatible way before we declare it to be a 1.0 that folks can build production storefronts that run on Shopify. And then we have to maintain for a while. So this is a build production storefronts that run on Shopify. And then we have to maintain for a while.

So this is a really good time if you're just curious about what is React Server components? What is suspense? How do I do server-side streaming? Like go kick the tires on this thing. Play around. And I think we made it really simple for anyone listening to this.

If you just type in hydrogen.new in your browser, it will open up a stack Blitz-powered type in hydrogen.new in your browser, it will open up a StackBlitz powered dev environment that runs completely in your browser and you can just start hacking right away. It's a really awesome experience. That's cool. Yeah, give that a try and just see how it feels

and if you find something that's really throwing you off, open an issue on GitHub or ping us on Twitter and I'd be curious to hear how folks experience it. Side note on StackBlitz, we did an excellent episode of JS Party about that

with one of the StackBlitz people. Really cool stuff they're doing over there. So we'll cross promo that episode. I learned a lot from it and it's cool to see you guys using it in this way that really just lets you

test the waters like immediately right there in your browser pretty awesome does that point at some sort of like a shopify demo or is there data available to be playing with or what yeah yeah so i love stacklets i think i've demoed it to many folks and i think it takes most like at least a few seconds to really click what happened because all they did is like they tapped the link or they typed in the URL and all of a sudden they're looking at an editor. Right. So it's like it's a VS Code environment. Everything's virtualized, including your server runtime. And under the hood, what it does is it basically clones the Hydrogen repo.

And Hydrogen comes with a starter template, which is hooked up to a demo Shopify store. So right from the get-go, you have a preview pane on the right, which is the actual live website, with some example data, like product data and components. So you can just start fiddling with it, right? And change the product description or something else and get a feel for how it, A,

feels to work with this technology stack, but also for how's the shape of the data laid out at Shopify and what are the hooks that we provide? We talked about components, right? So we provide a set of components optimized for Shopify. So they know how to intake Shopify GraphQL and render out common things like variant pickers, product carousels, carts, and all the rest.

But we also provide data loading hooks and a set of cache APIs and fetch primitives such that if you want to integrate with, let's say, a third party CMS because you're storing your marketing content in, I don't know, Strapi or Contentful, you can do that too. And we provide a set of built-in hooks for caching. So we try to build in smart caching strategies by default so you don't have to add it after the fact. We do it for you in an opinionated way,

but give you the power to override them. So we'll make choices like we will cache all third-party responses for up to 10 or 60 seconds. We will do async revalidation in the background. So stay a while to revalidate. So you don't have to block in every response. But if that doesn't fit your particular use case, you can just drop into the config and

change that to suit your particular needs. I love the Easter egg. You mentioned Toby earlier and the launch of Shopify being a snowboard store. I love the Easter egg here. I'm not sure this is intentional. I assume it is based on that. But like it's the store that launches in here is called Snow Devil and it's a collection of snowboards.

Yeah. So just to bring it back, Snow Devil was the original name for Toby's store. And one of the internal missions, if you will, was imagine you were toby and you were starting snow devil today what would you pick you know back in the day he was a rails contributor he knew rails so he started built like he was working on active merchant so he started building on rails but today if toby was starting to build a store and he was a developer what would he pick right and our hope is that you would consider hydrogen because there's a platform it's optimized for

commerce it has the right hooks and all the rest so yeah it's a little bit of a homage to uh like rebirth of shopify even the art's very nice too obviously i mean this is uh you got hydrogen is one of the arts on here you got've got the full stack, actually. Not full stack, but the full stack. And it's a stack of just servers or something like that. Squares in 3D. Liquid. The liquid is on there.

And then the first one, which is the toggle. I love it. Attention to detail. Yeah, we definitely went all 90s retro on the website as well. So if you go to hydrogen.shopify.dev, that's the landing page which talks about the high-level value prop and features. I recommend checking that out. It also links out to some example repos for, for example, Shopify Supply.

Shopify Supply is a Shopify store with like various merchandise and we're rebuilding it on hydrogen. So you can poke around that and just see how the team is progressing there. I mean, I want to go buy one of these snowboards. You got morning, evening and night for the hydrogen board. I mean, you've even themed the variants,

you know, speaking to the complexity of what happens in commerce as you've got the variants issues with different products out there, I mean, I'm going to buy the nightboard right now. A brief detour. So yes, we offer Shopify components, but I think one of the superpowers that we can do here is

it turns out that humble things like a product carousel turn out to be incredibly complex. You start with a very simple like i just need to show an image for my snowboard before you know it it turns into well actually i have multiple images okay fine i also have a video i'd like to play maybe you want to inject a 3d model in there by the way it needs to be swipable then i mentioned it needs to be zoomable because i really want to see that artwork on this damn thing. And of course, it has to work on desktop and mobile. So it has to be touch friendly. Obviously, it has to be accessible. And don't forget about SEO for all of these things. And on top of that, it has to be

performant too. So don't just like blindly load all these images, you have to have a really smart loading strategy for how to do all these things, right? And before you know it, you're looking at a product spec for something that started simple, but it turns out to be incredibly complex. And when you audit most stores, you'll find that they fail across many of these dimensions. And one thing that we can do as Shopify is we can amortize that cost, right? We be working with millions of merchants. We can do the research. We can figure out what is actually a good variant picker experience

based on qualitative research, based on data that we gather from our merchants, and transfer that knowledge as defaults into your variant picker. Does that mean that every storefront needs to use the same variant picker? No, of course not. But it's probably the right starting point for most. And if nothing else, it's a good reference point. So you can take that code and make it your own and you don't have to reinvent that wheel. This episode is brought to you by Sourcegraph. Sourcegraph is universal code search that lets you move fast, even in big code bases. Here's CTO and co-founder Byung-Loo explaining the problems that Sourcegraph solves

for software teams. Yeah, so at a high level, the problems that Sourcegraph solves, it's this problem of, for any given developer, there's kind of two types of code in the world, roughly speaking. There's the code that you wrote and understand, like the back of your hand, and then there's the code that you wrote and understand like the back of your hand. And then there's the code that some idiot out there wrote. Or, you know, alternatively, if you don't like the term idiot, it's the code that some inscrutable genius wrote and that you're trying to understand. And oftentimes that inscrutable genius is like you from, you know, a year ago. And you're going back and trying to make heads or tails of what's going on. And really, Sourcegraph is about making that code that some idiot or inscrutable genius wrote feel more like the code that you wrote and understand kind of intuitively. It's all about helping you grok all the code that's out there, all the code that's in your organization, all the code that is relevant to you in open source, all the code that you need to understand in order to do your job, which is to build the feature, write the new code, fix the bug, etc.

All right, learn how Sourcegraph can help your team at info.sourcegraph.com slash changelog. Again, info.sourcegraph.com slash changelog. And by our friends at FireHydrant. FireHydrant is the reliability platform for teams of all sizes. With FireHydrant, FireHydrant is the reliability platform for teams of all sizes. With FireHydrant, teams achieve reliability at scale by enabling speed and consistency from a service deployment to an unexpected outage. Here's the thing.

When your team learns from an incident, you can codify those learnings into repeatable, automated runbooks. And these runbooks can create a Slack incident channel, notify particular team members, create tickets, schedule a Zoom meeting, execute a script, or send a webhook. Here's how it works. Your app goes down, an alert gets sent to a specific Slack channel, which can then be turned into an incident.

That will trigger a workflow you've created already in a runbook. A pinned message inside Slack will show all the details, the JIRA or Clubhouse ticket, the Zoom meeting, and all of this is contained in your dedicated incident channel that everyone on the team pays attention to. Now you're spending less time thinking about what to do next, and you're getting to work actually resolving the issue faster. What would normally be manual tickets across the entire spectrum of responding to an incident can now be automated in every single way with FireHydrant. And here's the best part. You can try it free for 14 days. You get access to every single feature. No credit card required at all. That way you can prove to yourself and your team that this works for you. Get started at firehydrant.io. Again, firehydrant.io. We talked in the pre-show about Amazon having the commerce cornered, essentially.

And I don't think that's true. For me, when I shop at Worldwide Cyclery or KidsAnthem.com, which is the store I mentioned earlier, my neighbor's store. When I go through the checkout process and I see that Shopify checkout process, I can almost trust that merchant even more because I just know that Shopify's brand cares so deeply about this cool stuff. And this journey for developers, like you can go to any startup out there, the opportunity for a developer where they can go to make their next dent in the world, their next impact in the world is not limited now. Now you have the opportunity to build for great merchants on Shopify because you've enabled great dev tools. You said before limited by liquid.

Yeah, you had some great tech. Their theme kit was awesome, but it had its limitations. And I think now with how the stack integrates all this stuff, like it's just, I said floodgates early because I think like the future is floodgates. Developers are going to like cling to this and build the next best thing for their neighbors. You know, that person who was an entrepreneur who should be on Shark Tank that may or may not be pitching their thing. And now you're buying their stuff because they have maybe one or two developers to work with

them or whatever to make their Shopify experience amazing. Using great dev tools, not just cobbled together things that have been cargo culted from Ruby on Rails days that still work, that are amazing technology. It's not anything bad about Liquid, but it's got limitations for the next front-enders, full-stack devs making real impact. And I think that's why I'm so excited about what's happening here. Beautifully said. And it's not just Shopify either, right? I think what you said here

is about enabling more entrepreneurship and more commerce on the web broadly. And there's a lot of different teams, a lot of products making really, like building really interesting technology to enable that. I think Shopify has a key role to play here as both a one of the largest platform providers. And you're, I think you're seeing us

make that transition from kind of a fully integrated infrastructure into more composable building blocks for developers, oxygen, hydrogen, more flexibility, even things like get integration, right? It wasn't that long that you didn't have that. It's only within the last couple of years that we enabled that. So just allowing that flexibility. So if nothing else, if this is a world that is of interest,

and I think this is a world of a lot of potential as a developer, if you have React experience, I think it's a really sound investment of your time to learn a bit about commerce. Because as you said, there's lots of merchants out there that need your help right and it's a really robust ecosystem that you could make a really good living at it's an untapped market in my opinion for developers out there

listening it's an untapped market it's like walking into a room with mad skills and everybody wants them you know i mean that's what it is like there's so many merchants who trust shopify who they want to direct to consumer that's what it is is. Like they may or may not be on Amazon. This is kind of getting in the weeds of like choice and entrepreneurship and how they choose to deliver their products to wherever, I just think that's just a huge opportunity. There's so many people out there waiting for developers to make and deliver more tooling on top of this and to leverage what you've built to make their stores so much better. Yeah, yeah. I can imagine that like at some point because of Shopify and the way you all think that you may have some sort of support mechanism to train or provide docs or some sort of university or course that can help developers get to speed even more so on what React is. And this is now an entry point. We may say, I'm not a developer, I'm a Shopify developer, because it's specific to only commerce, only on Shopify, because it has that much potential. Yeah. So I'll plug a little bit about Shopify here, because we can unpack this, what you said,

into different aspects as well, right? When you think about the Shopify ecosystem, there is a huge number, millions of merchants today that are looking for some customization, right? And that could be as simple as I'm non-technical. I need someone who knows how to navigate through the admin panel all the way through. Maybe I need some CSS configuration in my theme to just kind of tweak it to my liking. You can apply your skills today to that.

Beyond that, there's also opportunity to build extensions to Shopify. So there's this whole ecosystem of Shopify applications, same thing as like iOS and Android applications, you can build applications that extend your back end capabilities, maybe have an idea for a t shirt store, right. And there's a specific logistical things that you need to do to run that sort of business, you can build an app that tailors to that use case.

And you can plug that into Shopify such that when a merchant comes and says, I have a need for that, I can just install an app and use that. And Shopify provides all the monetization primitives and all the rest. So there's the app ecosystem. There is the, I'm an indie developer,

maybe I'm an agency specializing in building this stuff. And then there's the, like, I work with a large merchant as a full-time or as a contractor, and they want a custom thing. That could be a web front-end. It could be the next AR, VR experience. Actually, we're seeing some really cool innovation with AR and VR.

And it still, I think, feels like hype for a lot of folks, but there's some really cool stuff being built. Like if you've opened the Allbirds app on your phone, It still, I think, feels like hype for a lot of folks, but there's some really cool stuff being built. Like if you've opened the Allbirds app on your phone, you can actually try on the shoes virtually, just on your foot. Is it as good as real life? No, because you don't have the tactile feel, but it's still really damn cool to be able to swap through colors and just see them right on your feet, and that's really neat.

And then there's examples like complex con so a large event for sneaker community last year but because of covid they couldn't meet in person so the whole thing happened online it was a virtual world it had commerce built in it was powered by shopify so it's a game that you venture through and you could you know walk into a room and go into a panel which would be a video stream. It's like, it's completely re-imagining the experience way beyond everything we talked about here. It's not touching React.

It's not anything else. But once you have the right primitives, once you know how to think about commerce and all the possibilities it can unlock, to your point, I think it's just such a vast playground. So do you see this? I know it's not fully formed yet. Hydrogen, like you said, developer preview. Oxygen, not even available yet. It's going to

be a 2022 thing or maybe closed preview. What's the state of Oxygen? Oxygen is in closed beta with a set of merchants right now. So there are folks running on Oxygen, but we're still hiring out some of the infrastructure to do like effective routing, some of the security bits and all the rest so our plan is to make it available in early 2022 by then we hope that hydrogen will be in robust enough shape as well so we can actually recommend folks to write and deploy production apps on top of this infrastructure i'd imagine hydrogen requires oxygen we're getting kind of maybe in the h2o world potentially with actual chemistry and considering which recipes make something.

But you can go now to hydrogen.new, and that's what you can play with. Beyond that, you would need oxygen to throw the React code over the wall, as you said, and run it on Shopify's infrastructure. It's still decoupled. It's not ready to do beyond what you're doing, right? Is that where it's at? Yeah, so the way I think about developer preview is ephemeral environments that you as a developer

can spin up quickly, play around, test, figure out if this fits, give us feedback, and all the rest. At the end of the day, it's server-side React code. And if you can run server-side React code on your platform of choice, you can run Hydrogen. There's no direct coupling to Oxygen. So in fact, if you go into our documentation,

you'll find some docs on how do I run this in a Docker container. So you could throw this on Linode if you wanted to, or even try to deploy to Cloudflare workers. Our bet is that long-term, in order to unlock the full power of dynamic commerce, you do want that rendering and data collocation and capabilities. And most merchants don't want to think about

writing Docker configs, and commerce at scale is not a Docker container, right? It is a fleet of Docker containers that you need to orchestrate, and you need to figure out the CDN and all the rest. We take care of that for you. So you don't have to use Oxygen. You can use Hydrogen, query our GraphQL API, and run it on your own infrastructure.

Totally fine. But I suspect that most folks will find a lot of value in just deferring that problem to Shopify to say, you guys know how to run commerce. Why don't you do that for me? So if this is a current bet, then what bumps do you see along the road? Like what, sure, you're in developer preview with hydrogen, you're in closed beta with oxygen. What are some of the bumps anticipated? What are some of the most technical challenges you're currently tackling as a team? What's the next few months for both these projects? I think there's still a lot of unproven technology in the react

space right so adopting suspense adopting react server components there's a promise of optimized bundles but a lot of the tech is still being built it is being experimented with right now by our teams so i think all those are solvable problems the question is how quickly right like is it a month problem is it three months problem or is it a three-month problem or is it a 12-month problem? And I suspect that it might actually be a 12-month plus problem for the React ecosystem at large, but it might be a much shorter timeframe for the needs of Hydrogen and Shopify

because, as I said earlier, we don't have to think about the existing ecosystem and how do we move them over and all the rest. So we can stack these technologies in a more opinionated way and kind of be more forward looking. At the same time, that also means that we need to spend a lot of time on education, which comes back to your earlier point of like, I'm not a React developer, where do I start? How do I learn about React Server components? I think that's a role that we will have to play. We will have to partner with the React team to figure out how to tell that story right and make sure that it actually resonates and blends right.

On the platform side, running a production platform at scale is a non-trivial undertaking, right? So there's lots of work that we need to do under the hood to provide the right security, isolation. We have some very large stores running some very large record-setting sales, right? So we need to ensure that we provide the right amount of scalability while at the same time maintaining efficiency, right?

One could imagine that you isolate every shop to provide the best performance. You know, everyone lives on their own Docker container, but that quickly gets out of hand. So how do you navigate through those waters as well? That's a lot of stuff that we have to think about to provide the best performance. You know, everyone lives on their own Docker container, but that quickly gets out of hand. So how do you navigate through those waters as well? That's a lot of stuff that we have to think about that as a merchant, you shouldn't and won't have to think of it.

But there's still lots of questions to answer there. That said, once again, we come back to, this is about server-side streaming. This is about isolation, this is security. These are all problems that have been solved by smart people before. We'll solve them here. So it's more a question of timeline than it is about, you know, is this actually technically

possible? Yeah, it's just a time problem, not a unproven concept problem. Yep. Yep. So when this is fully formed, do you imagine that developers will be able to create things that they can't currently create on Shopify? Or do you think this is more about speed to creation, developer experience, and making the hard parts easy, not having to worry about the accessibility

and the speed of the rendering? And a lot of the parts that you have to think about having that stuff taken care of as part of these components, or do you think this is going to unlock new capabilities for devs? I think it is both. I think it is going to unlock new capabilities for devs? I think it is both. I think it is possible to do the things that we described, like really high performance,

dynamic commerce with A-B testing and all the rest. But that has been the main of very few, very well-resourced engineering teams, typically at large organizations, because you can only absorb that amount of cost and pain, technical pain at that scale. And because of that, I think we're not seeing the amount of innovation that we could, you know, in the kind of medium and smaller scale merchants. Questions like A-B testing. A-B testing is still a dark art for most folks.

It is technically complicated. Large organizations typically have to have entire engineering teams dedicated to this sort of thing. So one question that would be interesting to explore is, and this is, I think, both opportunity for Shopify and developers building apps on top of Shopify, is to think about how would you deliver an A-B testing experience that a non-technical merchant could actually understand. And how do I provide that user interface that A, just allows them to create that test,

but then manages the entire deployment while not destroying the performance of the website? It's possible to do A-B testing before. Typically how that's done is you drop a JavaScript snippet on your page, which blocks rendering. Then you get a beautiful WYSIWYG editor that you tweak the strings or description or price even. You hit save, and it dynamically re-renders the page after it's loaded on the client.

It's actually a really good merchant experience, but performance-wise, it's a disaster. Why can't we have both? And I think that's like, if you just tap on that and all the related questions around localization and pricing and discounts, there's so much to be built in the space still. And I think that's an opportunity for developers, as I said, to build apps and for Shopify as well. Do you think there'll be any ripples in the water,

so to speak, with regards to the greater developer community beyond Shopify from your work on hydrogen? It seems like oxygen is clearly Shopify's side functions, but the open source side of hydrogen, is there fruit coming out of that for folks who aren't going to build on Shopify or is it all simply scoped to Shopify? I think so. I think the work that we're doing, for example, with the React core team to validate and prove out React server components will have a huge impact for the React ecosystem at large. I guess, conditional on your belief that React server components are going to become the de facto standard for React.

I am betting on that future. I think it will take time, especially if you have existing apps, but it feels right based on our experience. And we're working with a team now to figure out things like, yes, in theory, it allows more effective bundles, right?

So the idea is that you could isolate code that only lives on the server and not ever export it to the client. But in practice, like how do you actually hook that up? How do you make that work with Webpack? How do you make that work with Vite? And there's a lot of gnarly technical things

that are still being built. So we're working through that now. And once that lands, that benefits everyone in the ecosystem, not just Hydrogen. Cool. The final tweet in your thread, whenever you announced all this work and what you're doing here and whatnot, it mentions you peeking at your 2022 roadmap and saying, in quotes, much excite. So I think the first and major milestone is getting

this to production quality and getting real merchants shipping stores, right? That's the obvious next step. That's true for hydrogen. That's true for oxygen. I think there's a lot of potential for us to innovate on both. If we take them in order on oxygen side, yes, it's a worker runtime that accepts JavaScript code, but we're not just a generalized worker runtime. We're powering commerce. So what kind of specialized APIs and services that we can provide alongside that runtime,

that's supercharged commerce. Like maybe it's something related to A-B testing. Maybe it is a better set of caching primitives. Maybe it's something related to A-B testing. Maybe it is a better set of caching primitives. Maybe it's CDN. Like there's a lot of opportunity here. I like the maybes. Right, right. I like the maybes.

Maybe it's this, maybe it's that. Yeah, so if you just put on your thinking hat and say like, if I was building a hosting platform specialized for commerce, what are all the fun toys and capabilities that I could add in there that really make it more fun, more easy and more scalable to build high performance storefronts? That's a different take than I need to build a general purpose runtime that allows you to run

anything under the sun, right? Like, could you run a blog on the same infrastructure? Sure. My guess is you'll find better tools for that though yeah because we're going to specialize in commerce in the same way for hydrogen i think there's still a lot of unanswered questions on the actual technology choices as we just described really investing into the components following up on that vision of making them reusable, not just in Hydrogen, but if you want to use them in other React frameworks, let's make that work. Also going one level down and saying which of these can we hoist down into the Web Component layer, right? And just kind of bind into the React.

So if you want to use another framework entirely, you shouldn't have to reinvent the product carousel. That should just be a thing that you can just import and then customize to your needs. So expanding the options, I think, is another avenue with a lot of leverage for us. Very cool. Ilya, it's been great catching up. I'm glad to have you back on this show. It's been too many years. Hopefully we get you back with some of these realizations,

some of the maybes of this roadmap solidified that can be talked through. Anything else left unsaid? Anything else we didn't ask you about that you want to share before we go? Try hydrogen.new. Type that into your browser. If you want to read the docs, hydrogen.shop.quai.dev.

And please give us feedback. Cool. All right, Elio. It was great having you, man. feedback. Cool. All right, Leo. It was great having you, man. Thank you so much. Thanks, guys. That's it for this episode. Thanks for tuning in.

What do you think about the proverbial floodgates being open for Shopify developers? Is this something you're considering? Are you excited about their moves to support React, React Server Components, and this hosted V8 JavaScript Worker Runtime?

It's going to leverage all their platform. Is this exciting to you? Let us know in the comments. If you haven't yet, check out Changelog++. Support us directly and make the ads disappear on all our shows. Check it out at changelog.com. Up next is Jessica Lord on GitHub sponsors and the origins of Electron.

Also on deck is DevDiscuss from Dev. Right here on the changelog, Jared and I guested their launch episode for season seven, so we're bringing that here for you. Thanks again to our partners, Linode, Fastly, and LaunchDarkly. Also thanks to Breakmaster Cylinder for making all of our awesome beats. And, of course, thank you to you for listening.

If you enjoyed this show, do us a favor. Share it on Twitter, Reddit, Hacker News, anywhere that works for you. Word of mouth is by far the best way to help us grow this show. And, of course, the Galaxy brand move is to subscribe to our master feed. That will get you all of our podcasts in one single feed. Check it out at changelog.com slash master. All right, that's it. This show's done.

Thanks for tuning in. We will see you next time. Go, go, go, go, go, go. Thank you. Nå er det en av de fleste som har kastet seg i en av de fleste av de fleste. Outro Music