Today we talk with Josh Larson a senior staff developer at Shopify who is front and center in development of Hydrogen.  We learn how Hydrogen addresses the varying needs of shop owners to build storefronts quickly and effectively.  With rendering on the server only, this metaframework provides a toolkit helping customers build a more customized web presence.  We learn about Oxygen, which allows customers to host and deploy Hydrogen.

We also discuss the decision behind the decision to use React to build this framework, how the framework provides super-custom experiences for the user, and discuss some of the technical challenges faced when building it.  

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of the JavaScript Jabber podcast. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from the garage. Yeah. All right. 

CHARLES MAX_WOOD: We also have Dan Shapir. 

DAN_SHAPPIR: Hey, from Tel Aviv. 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devs. And this week we have a special guest that is Josh Larson. Josh, do you want to introduce yourself? Tell us what you do over there at Shopify.

JOSH_LARSON: Yeah, hi everybody. Thanks for having me. Josh Larson here. I am a senior staff developer at Shopify and I live here in Des Moines, Iowa. I've been at Shopify for a year and a half now building Hydrogen, which is our custom storefronts framework that we're going to chat about today. But yeah, that's, that's what I work on over at Shopify. 

DAN_SHAPPIR: So you work with Ilya Grigoriev? 

JOSH_LARSON: I do. Yep.

DAN_SHAPPIR: That must be fun. 

JOSH_LARSON: Yeah, he's a really brilliant guy and loves to chat about performance and caching and all sorts of stuff that is really closely related to hydrogen and oxygen. 

AJ_O’NEAL: Performance is not jammed. 

JOSH_LARSON: Yeah, yeah, us too. Yeah. 

 
Hey folks, this is Charles Max Wood from Top End Devs and lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs why I changed it from DevChat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with DevChat.tv. I renamed it to Top End Devs because I want to give you the resources that are going to help you to build the career that you want. Whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world, whatever, I wanna give you the resources that are gonna help you do that. We're gonna have career and leadership resources in there, and we're gonna be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th, if you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

CHARLES MAX_WOOD: Man, Shopify, I remember way back in the day when Toby started it and he was coming to the Ruby conferences and talking about what he was building. So it's come a long way since then. 

JOSH_LARSON: It definitely has. And like, it's been super fun to work with Toby on the hydrogen project, especially. And I don't know if you all have seen it. The demo that we did about a year ago in June at Unite last year where Toby did a quote unquote live coding of hydrogen and walked people through what hydrogen was. So it's kind of cool going back to the roots of Toby hacking away at his snow moved on to to react. 

DAN_SHAPPIR: It's cool to have a CEO that can actually code although you know what it is kind of common I guess with high tech companies 

JOSH_LARSON: Yeah, is it I as the first CEO I've worked for that codes. 

CHARLES MAX_WOOD: I think it depends in the case of Shopify he was a founder and he's been able to Guide the company in the direction that it needed to go without having to bring in somebody else to kind of push through the next growth stage or whatever he's done a fairly excellent job at that. And so, yeah, usually what happens- 

DAN_SHAPPIR: It's a benign statement. 

CHARLES MAX_WOOD: Yeah, a little bit. But the deal is that I've seen, and then we'll dive into the topic here, is that, yeah, so you'll have a technical founder, and then after you get to a few million dollars in annual revenue, something will stall out, and then you need somebody who can come in and kind of guide it through the next phase. And then what you do is you wind up swapping out CEOs when you get to the next stage. I tend to see this more in companies that are funded though, and I don't remember if they bootstrapped Shopify or if it was funded. So anyway, but let's dive into oxygen and hydrogen. 

JOSH_LARSON: Let's do it. 

CHARLES MAX_WOOD: And we've kind of talked a little bit like we know what it is because we've been talking before the show recorded, but let's just assume that our listeners don't know what it is. So can you tell us what it is and why JavaScript developers should care? 

JOSH_LARSON: Yeah, absolutely. So a little bit about Shopify for folks who are familiar too, is that it's been around for more than a decade and it's been home to many, many merchants and people building shops and selling things online. And Shopify has been known for its online store presence, right? You go in, you can pick out a template, customize that template, install apps and do all sorts of things. And the traditional approach to this has been through a templating language called Liquid rendered in Rails. And it's super powerful. It's not technically like a programming language, but it's a templating language and you can get a lot done with Liquid. But recently you've probably heard the term headless commerce. It's kind of the hot new thing in the community and developers want to use what they're familiar with. And that tends to be React, it tends to be Vue. The modern JavaScript frameworks have grown tremendously. And in order to use those with Shopify, you could use those previously. You could build on our storefront API and build your storefront using whatever tool set you want. But what we found was that it is actually pretty difficult to do. As soon as you get off the well-trodden path, I don't know if that's the right way to say it, but the online storefront off of Liquid, you're kind of on your own to do all these things from scratch. You have to build not only the design of your site, but you have to handle cart interactions and accessibility. And performance, of course, authentication, routing, like all the stuff that you kind of take for granted when you're on the platform. 

DAN_SHAPPIR: Scalability, security, all the, you know, all the nice things compliance. 

JOSH_LARSON: Yep. And like you have to worry about, you know, at midnight is my site still up versus at Shopify that we take care of that for you with your, your liquid online storefront. And so a little over a year ago, we started really focusing on this, this quote unquote, headless experience. And it's. It's funny because headless is a weird term. It's essentially just use the APIs. So internally we refer to it as custom storefronts. And we wanted to make- 

DAN_SHAPPIR: Just to clarify, before you continue with that, that API I believe is GraphQL based, correct? 

JOSH_LARSON: It is, yeah. The storefront API is GraphQL based. 

DAN_SHAPPIR: Cool. 

JOSH_LARSON: Yeah, we have a storefront API, which is meant obviously for storefronts. And then there's an admin API for integrating with the the administrative side of your shop also for app developers to use as well. So the hydrogen and oxygen came from a renewed focus on the importance of custom storefronts and helping out our merchants who previously had to do all these things on their own as soon as they wanted to break out of the liquid storefront. 

DAN_SHAPPIR: Again, I apologize for interrupting, but just to get a grasp, I don't know if you can actually give numbers or if these are like corporate secrets or whatever, but what percentage of merchants actually wanted to build their own storefronts? Like how common was this thing? 

JOSH_LARSON: It's a good question and I genuinely don't know what the percentage is. It's really interesting to look at not necessarily the merchants who have made the switch, but the reasons why they want to make the switch. We found that even before I joined Shopify, I think there was a lot of exploration into, okay, we have these requests that people want to build custom storefronts. why not use liquid? And it turns out like, oh, okay, this thing, which is very common in the modern development community is very difficult to do in liquid. Oh, maybe we should focus on that for a store. Huh, the popular themes are really slow and not performing well in browsers. Oh, maybe we should focus on that. And so at last Unite in June, we actually announced kind of online store 2.0 to address a lot of those things that were driving merchants to go the custom route when really they probably could have stayed on the standard route. I think another thing we see is once merchants get to a certain size, I think there's pressure to break off and build a completely custom system, maybe to integrate more deeply into a content management system or I don't know, all the dozens of other APIs you might have as part of your business. So yeah, I don't have numbers, but those are the reasons we saw. And so that kind of gave us a purpose for not only improving our existing offering, but building something new that can help those folks. 

DAN_SHAPPIR: Yeah, it kind of reminds me of this statement that I've heard once, which kind of says that not being required to code is great, but not being able to code is terrible. So I guess that the ability to kind of break the mold when you need it is a need, certainly when you grow large enough and you have a wide, a sufficiently wide variety of customers. 

JOSH_LARSON: Yeah.Yeah, it's so interesting to look at the landscape of like, who are, what's our target audience? Is it the no code developers who are comfortable jumping into an editor and like uploading a logo or changing a color swatch or something? How much do we cater to that audience that might be, it might be developers, but it's probably marketing people. It might be just shop owners with a really smaller merchant versus like, when do we start requiring people to jump into code? When do we require you to edit a liquid template, right? Or learn what liquid is. So It's interesting to cater to multiple audiences. 

DAN_SHAPPIR: So you were saying that you realized that you needed a solution that would enable developers to actually create their own custom store, whatever it is, but still hand off a lot of the nitty gritty of store management, whatever that means, to you guys. And you said that previously, if they wanted to do that, they could via your storefront API. That's the name again? but that it could be fairly challenging because effectively they were going from being a hosted type solution to effectively a self-hosting type solution where they really had to take care of everything. And I guess from what you're saying that is that the combination of hydrogen and oxygen are your solution for this kind of conundrum. So can you elaborate on what they are exactly?

JOSH_LARSON: Yeah, exactly. Yeah, let's let's jump into the actual definition of these things. So so hydrogen is a JavaScript framework. It's a React meta framework that allows you to build custom storefronts quickly and effectively. This is our answer to building out your custom storefront in a way that doesn't require you to start from scratch. It doesn't require you to reinvent every single thing and and build everything from the ground up. It's a toolkit. It's it's a lot of things. So we provide out of the box these user interface elements, so cart buttons to add items to cart, all sorts of stuff that's just kind of baked into traditional commerce templates. But hydrogen is a little bit more than that. When we were kind of surveying the landscape of modern frameworks, modern JavaScript frameworks, we saw this kind of tendency to go toward static site generation that ensured like super fast performance, right? Because you're not rendering a fresh page on the server every single time. And that was great, but it also introduced some other problems, right? You have to revalidate those pages. You have to, anytime you publish a product, you might have to bust the cache and regenerate your entire site, which might be thousands and thousands of pages. So we didn't think that would be a solution. And around the same time, React announced this new thing called Server Components, which you may or may not have talked about on the show before, but this is kind of a new experimental approach to rendering components on the server only, not on the client. And we really liked that paradigm. And it also played into the idea that we think the commerce is inherently dynamic and it's not something that ought to be statically generated because you're always selling things, you're always changing things, and it's also important to have personalization in your storefront as well. And so that led us to build an entire kind of meta framework around the idea of React and React server components. 

DAN_SHAPPIR: So first of all, I would like to just to mention to our listeners that we did cover or actually touch on React Server Components in one of the episodes about React that we did a while back. I talked briefly about the motivation for them and what they are, so our listeners can go back and listen to those episodes if they're interested. But it does bring up a question for me. So when you first announced Hydrogen, and also again ahead of this recording, I went and looked through the documentation that you have for Hydrogen because the documentation has been out for a while now, and also the various demos and example applications that you have. And by the way, I have to congratulate you on the use of StackBlitz. The way that you do, the fact that you can launch a demo development environment and start actually coding without having to install anything just by clicking a button or a link is awesome. And by the way, we also had the CEO of Stackless on our show discussing this technology. So the fact that it's made, it's used in such a great way is really great. I really loved it. Yeah. And I highly encourage all our listeners to try it out because it's like I said, you don't really need to install download anything. You're not going to leave any junk on your computer. You just click a link the new tab opens, it's got a VS code environment in it, it's got node in it, then you can start testing out code. And that's really great. So the one thing that kind of surprised me when you announced it, so I was really expecting you to come out with a set of components, which you did and the various, for example, custom hooks that you created for working with the APIs, which again, you did. What kind of surprised me was the fact that you decided to build an entire framework for it. I was kind of expecting you to integrate with one of the existing frameworks like Next.js maybe, or now we also have Remix, and there are probably others that I'm forgetting and Redwood, I didn't expect you to decide to build your own complete framework from the ground up, as it were. Can you elaborate on your motivation to do that? 

JOSH_LARSON: Yeah, for sure. It's a good question, isn't it? That's what we say. 

CHARLES MAX_WOOD: Because it's cool. Please just tell us this was because it's cool. 

JOSH_LARSON: Here's the reason because it was cool.

CHARLES MAX_WOOD: Oh, there we go. No. 

JOSH_LARSON: And podcast over. No, that that's a good question. And Yeah, I think that's fair to ask, especially in 2021, announcing something like, you've already got these really cool things. Why not just cater to those? And I think our approach has been twofold, I guess. One, yes, we do have components and we do plan to offer those and allow them to be used in Next and Remix, wherever you take them. And then eventually more components for maybe View or Svelte or I don't know what the next hotness will be. The reason to create a framework is, It creates a lot of opportunities for Shopify in general as a platform. Creating a framework lets us build a super custom experience for merchant developers creating custom storefronts. It allows us to mirror some of the behaviors we've created in the online store, you know, liquid world, some of the expectations there. It also lets us build a hyper-specific set of tools for personalization, customer integrations, authentication, talking to our own APIs. And yeah, that's where we ended up there. Yeah, it was an interesting decision, but I think it's gonna pay off tremendously for us. Under the hood, another thing that was happening at that time was this new tool called Vite had just come out, or at least V2 of Vite had come out, and it had like multi-framework support, not just, it was originally a Vue.js development tool, and now it's V2 supported React and all these other things. And since we announced Hydrogen and launched the dev preview, we've seen this huge, huge community adoption of Vite as a dev server. And Vite does a lot of the work, honestly, of Hydrogen as a framework. It made building and layering kind of custom framework-y things on top of Vite very easy to do, versus I can imagine building something with Webpack or something completely from scratch would be a lot more, a lot more of an investment.

DAN_SHAPPIR: So I apologize, but I'm going to push a little bit on that because I want this to be an interesting discussion. So let's say I am building a more sophisticated site where e-commerce is just a part of everything that I need to do. So there's a store, but there's also, let's say, I don't know, a blog or some sort of forum or the ability or whatever, I don't know. So there are a lot of components. Now, normally I would prior to hydrogen and being, let's say, a React developer, I choose, let's say, a platform like Next.js. Well, and because Next.js has this entire ecosystem where I know that it integrates with various things that Percel offers, there's the community, there are a lot of components and plugins out. Obviously, these are React components, so I guess I can use them in any React-based framework. But still, you know. The mainstream is kind of next to yes. Now we have Remix trying to give them a run for their money. We'll see how that goes. But still, it's like kind of become the kind of the de facto standard almost for an application framework on top of React. So my obvious question would be if a storefront is just a part of everything that I'm offering, will hydrogen be able to support all that, all that, and or will I need to kind of jump through hoops going, I don't know, doing some of my projects in hydrogen, doing some of my projects with Next.js? How challenging will it be for me, let's say as an agency or whatever, to be able to handle both these environments and both these frameworks? 

JOSH_LARSON: That's a, that's a great question. I love Next.js too, and I've, I'm really excited about the work they're doing over there and their new, you know, layouts proposal and huge fan of them in Versel. I think it will be interesting to see does hydrogen serve the needs of like you mentioned you, you if you have other things you want to integrate and maybe you feel like it's an XJS app with some commerce on the side, right? It's not a core. It's not just a storefront. It's a whole bunch of things. Is that like the common pattern? Will hydrogen be able to support all those needs? We certainly think so and hope so. On day one, maybe there's some missing APIs that we discover that we add into V2, V3, whatever. But yeah, I also don't think it's like a zero sum game. I think people will continue using Next.js and Remix is funny because they, I think they came out of their private beta in the fall after we had been working on Hydrogen for a while and it was like, oh, this is a really great framework. And so we're gonna work with those folks to create like a Hydrogen Remix stack for folks who really like Remix because it's also a really, really slick framework. So I would anticipate that folks will continue using what they like to use, but we also want to target the developers who are Shopify developers. Like you mentioned agencies too, which I think is an important note. Agencies are not looking to create the hottest new tech or the most experimental thing, right? Their job is to create products for their clients and get the thing out the door. So if we create something that's so difficult to use or requires tons of education, then it's gonna be harder for agencies to adopt that. And so That's what we've also been thinking a lot about. And we're working with a couple agencies right now to, to get really good feedback as we approach our 1.0 launch, which by the time this is released, we'll be out there. 

DAN_SHAPPIR: Well, yeah, obviously you have a big advantage there. I mean, you know, Shopify is obviously a huge brand in everything having to do with the e-commerce, even though all the e-commerce companies have shrunk a bit with the stock market, but still like you're, you're undoubtedly like the 300 pound gorilla in e-commerce sites, which aren't Amazon. And having your stamp of approval on a development platform, and I assume you're probably going to also have support for these developers or for these agencies. I guess that means a lot. Just like I said, initially that was my surprise about it, that I, I expected you to do something like that. I did not expect it to be like, all the way from top to bottom, the way that you decided to do it. 

JOSH_LARSON: Yeah, absolutely. You're not alone there. Yeah, I'm very curious to see, I've been heads down on this project for over a year now as we hit this milestone with general availability. I'm very curious to see how it's adopted and what developers do and whether they use it for the purposes we had anticipated, whether they find new ways to use it. And I fully anticipate we have a really, really smart team working on this product anticipate us to kind of adjust and add things, remove things as, as we see adopted use cases. 

DAN_SHAPPIR: So I'll throw you another curve ball and we can edit it out if it's too much of a curve ball, but you said that you were hands down on it. Can you give an example of one of the technical challenges that you guys ran into and really had to work hard about resolving, finding ways to, to work through work around whatnot? 

JOSH_LARSON: Oh my gosh. Which one to choose? I can give you, I guess, a more recent example. Generally, in general, the use of React Server components has been a lot of work and a lot of experimentation, a lot of smart solution finding, I guess. To get that to work, as I mentioned, it's super experimental, or was announced as being experimental. And so not only did we start using it before it was ready for production use, we created a version that worked outside of Webpack, which is what the original example was built in. And then collaborated a lot with the React core team and now the folks at Versailles who are building server components into Next.js and that server components, we think the, the fundamental design of it is, is sound. We think it's a good pattern. It's probably going to be the correct way to build react applications moving forward. The exact implementation details are the parts that have been changing, and that's also where we've been doing a lot of work. For example, with the initial prototype of server components that the React team announced, the way to designate a component as being server or client rendered was by using a file name suffix.server or.client. And after having gotten Hydrogen into use in production and also in front of agencies and developers, we started collecting a bunch of feedback that this paradigm was confusing and most notably, like a client component gets rendered on the server during server-side rendering, which may not be obvious to you when you see something labeled as client. So we've been delivering that feedback to the React Core team and iterating with them for the past few months on like, okay, how can we change the design of server components to better suit or be less confusing and be more scalable? So that's been a super fun adventure of like getting the thing to work finding ways to make it work better. And yeah. 

DAN_SHAPPIR: It's fun to be on the bleeding edge. 

JOSH_LARSON: Fun is one way to describe it. Yeah. 

 
Hey, folks. I'm here with JD from Raygun. JD, I mean, it seems like a lot of things these days are kind of pushing us more toward productivity, right? We install VS Code extensions. We do CI CD. We kind of get this stuff off our plate, automate as much as we can, and move quickly. And one of the tools that I tell people to get is something like Raygun. Do you want to just explain real quick how Raygun can help with the productivity? Yeah, absolutely. I mean, it's several fold. I like to think of Raygun as almost being like a full-time engineer on your team that's keeping an eye on things and is able to report the important faults or performance bottlenecks so that you aren't guessing. And so that's one element. But then to that point where we store all of the data we possibly can on the context of the error or performance issue we integrate with source control systems, you can jump into our APM and get method level timing details with the source code right beside it. So if you're looking at it going, why is this page so slow? You can usually just eyeball the code right there and then. So speeding everything up, which I think is really important with our industry is under so much pressure right now. We've got to try and get people be more efficient because we're not going to have a whole lot more people suddenly. Right, absolutely. And I just I love that idea. I've done plenty of optimizations myself, right, and having an APM tool that will actually say, yeah, this is the slow code, right. So instead of me trying to guess, or look at it and go, Oh, do I have an n plus one query here? Yeah, it just tells me where the problem is. And that's really powerful in something like raygun or Yeah, absolutely. I'm a huge fan of Iron Man. And then you know, the idea is that I would love a virtual Java's that's just going Hey, There's this thing. Do you want me to go fix this? Do you want me to solve that? It's like that's, that's what we need to get to. Yep. Absolutely. Well, if you want the next best thing, go to raygun.com and it's not Jarvis, but it, it will tell you where the problem is. So you can go fix it. You can get a free trial right now if you want this ray gun.com. 

AJ_O’NEAL: What's the point of having reacted all? Cause this seems to be the new trend is we're adding more layers on top of react so that react can not be react anymore. Like we don't like react do everything on the server side. Why not just go back to the old traditional, create a simple template file, and sprinkle in a jQuery when you need to click, and call it good. 

JOSH_LARSON: It's a good question. I think the first answer that someone will give you is that it's super popular. There's a huge ecosystem of React developers who are- 

CHARLES MAX_WOOD: We made it back to, it's cool, I like it. 

JOSH_LARSON: It's cool. This is the underlying theme here. I think, I don't know, it's a good question. And we see people use React and Vue in our online store Liquid templates as well, which are server rendered, right? But it would be client rendered React and client rendered view and all that stuff. I think people use React. So my personal experience is like, I like the componentization of React, the ability to encapsulate certain things and reuse them across your theme. It's kind of difficult to do that today in Liquid with the tools that we offer. 

AJ_O’NEAL: And we don't have a way to do that with web components yet. Yeah, 

JOSH_LARSON: web components, yeah, that's like, that would be the platform native way to do it. I think there's been research into server rendering web components and making them work. I, I, I don't know super much about 

DAN_SHAPPIR: Yeah, there is, there is some ability to do server side rendering with web components, but I'm not sure it's actually supported beyond Chromium, for example. So I don't know, for example, if there's Safari support for it, but yeah, we can conjure 

AJ_O’NEAL: up components were old news now, 

DAN_SHAPPIR: but web components are old news, but as clients side render, so you create. You basically run JavaScript on the client side that builds the Shadow DOM dynamically at runtime. If you want server-side rendering in order to achieve, you know, if you want to componentize everything, which means all your UI is web components, and you want to have good performance, then you need something like server-side rendering. Now they've added server-side rendering support into web components, but there seem to still be issues with it, but I have to confess that I'm no expert. Maybe we need to bring up Alex Russell on the show again to discuss it. I know that he's a big champion and proponent of this approach and a big criticizer of reacting in general. 

AJ_O’NEAL: On can I use, it looks like web components have been supported by every browser. 

DAN_SHAPPIR: Yeah, but again web components in general versus server-side rendering for web components. 

AJ_O’NEAL: I get that, but you said it wouldn't work in Safari and that's why I was confused. And so then I went and looked up like, wait, does Safari not have support for this? So anyway, so that was the sidetrack based off of that comment. 

CHARLES MAX_WOOD: Right. Then this is the question that I was going to ask was, you know, on the server components, you know, so why the heavy focus on server-side rendered stuff versus the front-end rendered stuff? Because a lot of your React developers are going to be much more familiar with client rendered client components than they are with the server rendered. Not everybody's pulling that trick yet out of their hat. 

JOSH_LARSON: Yeah, no, that's a good question. I think that server rendering is has been important in the past for search engine optimization, right? Yeah, I think crawlers are getting better at reading client rendered things. And it's probably less of a less of a thing. But it's also nice to have a separation of concerns. And I think that's probably one of the bigger benefits of the pattern of server components. I'm writing a component that I know is never going to get rendered in my client bundle. I can talk to my private sources. I can code up some countdown for a super secret flash sale that I'm having and no one's going to know unless they have access to my server code. 

DAN_SHAPPIR: As I recall looking at your documentation, the access to the GraphQL API for the storefront API is kind of a well, by default, restricted to the server side, correct? And it's not available from the client side. Obviously, I can create buckets of JSON data and download them to the client or pass parameters to my client's rendered components and then data back, but generally not access the API directly from the client side, correct? 

JOSH_LARSON: Yeah, that's actually a pattern, that was an intentional pattern from the beginning. We really want developers to make these queries on the server and it's not on the client. No, there are reasons behind that. Like, yeah, right. I mean, so our storefront API at Shopify is technically public. You get a public token and I think this has worked. It served us well for like, Hey, take this code, throw it on an HTML file, push it to your server and you can query your products. Right. I think what we've found over time is that as the Shopify platform has grown, developers and merchants are using the platform for more than just, this is a red shoe. They have inventory details, they have maybe sensitive data, customer information, like all sorts of cool stuff and powerful use cases, but you don't want to accidentally leak that into the public space. And so by setting kind of this pattern of server fetching, we can start to migrate developers to the correct path and introduce potentially maybe things that you can only access using a server token versus you have limited access on the client with the public.

DAN_SHAPPIR: I also wanted to say something in the context of AJ's question about why not use a more standard multi-page application, let's call it style architecture. And one reason that I can think of is that that type of architecture kind of requires you to have almost a different type of development going on on the front end and on the back end. It kind of creates a segregation between client-side development and server-side development. So the server-side development might not even be in JavaScript, but even if it is, it's a completely different set of APIs and technologies and approaches. And for an agency, let's say, requiring you to have back-end developers versus front-end developers for the same project can be challenging. And one, I think, advantage is of the React-type approach is it's not really a front-end developer or a back-end developer. It's a React developer that works on both sides of the divide. 

CHARLES MAX_WOOD: I think that's interesting. I find that the discussion over whether or not you have back-end versus front-end developers is often overstated. And in a lot of cases, you know, you can get away with the same set of developers doing both. But when you're getting into the server component part of this, right, where you're talking about server rendered things in React and then, you know, having that translate to the front end. That's where I'm seeing that ease of use, right? We saw a lot of people when Node.js came out, they were like, well, I could write JavaScript on the front end and the back end, and it was like, yeah, but you have two completely different sets of concerns, and so you're not really solving that problem. Whereas this is a little bit different approach because you're actually using React to do a lot of the work on the server side and on the client side. 

JOSH_LARSON: Yeah, I can see the consistency, right? Back and front end. I feel like the remix folks have said something recently where Remix is actually just less of a react framework and more of just like a full stack framework with some react sprinkled in. And I think that's kind of a cool analogy. Like I'm using one thing and it takes care of all the things for me. 

AJ_O’NEAL: So ever since he's gotten involved in remix, anytime I ask Kent C Dodds a question, he doesn't even read my question. He just says, but have you tried remix? 

CHARLES MAX_WOOD: That sounds like Kent. 

JOSH_LARSON: Yeah. Kent's great. 

AJ_O’NEAL: I tried to have a conversation with him. He's like, But remix solves this problem. Like, no, no, no, no, I don't need remix. I'm trying to consider this thing. Yeah. Yeah. Yeah. If you, if you remix like, Oh my God. 

DAN_SHAPPIR: Well, you know, if, if the, if the head dev rel for remix, isn't excited about all things remix, then he's not doing his job. 

AJ_O’NEAL: Well, I know. But if I say I want a glass of lemonade and you say, Oh yeah. So you can build a remix Shopify site and you can order lemonade. It's like, no, no, that's it's. It's a little, it's over the top. 

DAN_SHAPPIR: So, yeah, undoubtedly, undoubtedly we've created a bit of a monster. I mean, I can also kind of see Alex Russell's point here that we, and I kind of covered this in our episodes on React, that we created as developers, or the React people created what was originally a very simple model for building, for componentizing and create constructing front ends and then as reality hit and we encountered more and more concerns regarding performance, regarding scalability, security and whatnot, then the model became ever more complicated. And then we had to introduce application frameworks like Next.js, like Remix, and now like Hydrogen to deal with this extra complexity so that somebody else kind of encapsulates the complexity for you, assuming that you code according to certain guidelines or best practices or conventions or whatever. But again, it is what it is because like Josh said, at the end of the day, you have agencies that are trying to get their product out the door. So I'm betting that a year from now, we'll have hydrogen certified developers and they'll be able to crank out hydrogen based e-commerce sites. 

CHARLES MAX_WOOD: There you go. Yeah. Can I steer this car back onto the road? Cause I'm a little, I'm trying to figure out exactly how this fits in and why our audience is going to be interested in this. Right. So for one, I've talked to a number of Shopify agencies and they build plugins. They're usually built in Ruby on rails. They attach the backend and it seems like this is a way of, I guess the model in the past has been you have your Shopify site and then you have the rest of your site and this allows you to integrate. Directly, you know, on your on your main website, you don't have to go to a Shopify store with a subdomain or something like that. Am I understanding that right? Is that the difference here between the way you've done it and the way you're heading for now? 

JOSH_LARSON: I don't know. I would say that it varies probably from merchant to merchant. How core is the Shopify part of their storefront to their website? Do I have a store.mydomain.com? Then yeah, that'd be a little side shop or is it the main thing and it's integrating with every portion of your thing? 

CHARLES MAX_WOOD: Right. 

AJ_O’NEAL: What are people using Shopify for in general? What's your most, I guess, two things. What's your most common type of customer? What's the, what are the types of things they're doing with it? And then what is your, your best customer? 

JOSH_LARSON: Man, I should have studied on my Shopify notes before this. 

AJ_O’NEAL: But are we talking about selling mugs and t-shirts? Are we talking about people selling? artwork and crafts, what, 

CHARLES MAX_WOOD: what do people selling all kinds of stuff? 

DAN_SHAPPIR: It's everything AJ really. Yeah. The biggest, unless you're selling on Amazon, if you're building your own store with your own domain, there's a good chance that you're probably doing it on either Shopify or work, WooCommerce or, you know, maybe a Wix or SquareSpace. But Shopify is, is obviously the leader in this space. And it might be like a really small store that does everything with drop shipping. Or it might be, I think, your Nike or something is running on Shopify, if I'm not mistaken. 

CHARLES MAX_WOOD: Yeah. I guess, I guess where I'm leading with my question was, is this something that you expect in-house developers to pick up in order to integrate Shopify features into the websites they're building? Or is this more something that you're kind of handing out to the consultants that help companies where technology isn't their primary focus, right? They're worried about logistics and supply chains and stuff like that to give them an opportunity to build this for their customers. And then the other question that I'm gonna ask next is effectively, is this gonna become the new way of adding functionality to Shopify stores themselves? Or is that gonna remain kind of the way that it always has been? 

JOSH_LARSON: So I think to address both of those things, first, it's kind of like. Who's this for, right? Who do we expect to be using this? And we see, this kind of addresses AJ's question too, is like, who's using Shopify? We see all sorts of merchants from your very small, your t-shirts mugs, right? Or I have one product that I sell sort of thing, to companies who have IPO'd and gone public and they sell thousands and thousands of things. I think that we do expect in-house developers to pick up hydrogen and start using it to build their storefronts. We were working a couple of those right now, a couple of our larger merchants with their internal dev teams to build out a hydrogen version of their storefronts or maybe a new feature built in hydrogen. One company built a store locator with hydrogen. They're still running the rest of their storefront on Shopify's liquid storefront, but kind of incrementally adopting it. And you can also touch on another thing that's been a focus of ours, which is incremental adoption. Is this how I start? modifying and tweaking other parts of my Shopify storefront instead of just being a kind of a blanket, here's the thing, right? And that's, we've been focusing on that too. Like what would it mean if you could execute like a React component, have it be server rendered or be a server component without jumping all the way to Hydrogen and needing to hire a dev team and needing to do all the things like we mentioned that are required with going headless. What if I could just kind of incrementally sprinkle in some of these cool features into my existing storefronts. And I think that is also an incredibly powerful value add of hydrogen down the road. Something we're definitely looking into. 

DAN_SHAPPIR: I think the ability to let JavaScript developers and React developers build storefronts is just a plain powerful thing to do. I think beyond any additional thoughts and motivations, I would like to to steer us into one more direction before we wrap up. And that's okay, I developed my store using hydrogen or my website with a store using hydrogen and I now want to deploy it into production. Where do I deploy it to? And I guess that brings us to the discussion of oxygen. 

JOSH_LARSON: Yeah, yeah, oxygen is the partner of hydrogen, right? We spoke about- 

CHARLES MAX_WOOD: But do I need two hydrogens to make it rain?

JOSH_LARSON: You do, you know, to form a complete liquid, you do need two hydrogens and one oxygen. We talked about like, yeah, the cost of going custom is pretty high, not only in the development of your custom storefront, but then maintaining it, keeping it up, you know, handling scale, all that stuff. And so oxygen exists to answer that question. And oxygen is now generally available as of this airing. And it allows our merchants to deploy their hydrogen sites and host them on oxygen. I think. A funny realization that a lot of folks, including myself, have come to is like, oh, wow, Shopify's getting into the hosting game, when in reality, we've been hosting sites for a long, long time, right? They just have been liquid sites, and it's just a different type of hosting. It's a lot different and more complex and introduces a whole new set of challenges, but I think the end goal is to create an experience similar to the liquid storefront now, where I can click a button for my site to go live, and I can rest assured that someone who knows what they're doing is keeping that site up and making sure it's performing as needed and scaling as needed. I don't have to pay some, some person exorbitant amount of money to keep it running or based on the number of requests, that sort of thing. And so I think it's a really important product for Shopify to release alongside with, with hydrogen. 

CHARLES MAX_WOOD: I just want to be clear. So oxygen is effectively Shopify hosting my hydrogen site. So I don't have to go deploy it to Versel or Netlify or go set up a server somewhere. This is me saying, hey, I'm going to use hydrogen, but I want you to manage all the rest of the stuff, the deployments and all the hosting and stuff, so I don't have to worry about it. 

JOSH_LARSON: Yeah, exactly. It's got the things that we know and love about Vercell and Netlify, I think, are table stakes these days. GitHub integration, preview deploys, variable management, all that stuff, logs. And so those are included in Oxygen. It's behind the scenes. It's a V8 isolate a workers runtime as opposed to a Node.js runtime, but hydrogen is built to support both the folks at Netmify actually got it working on Deno too, or Deno, I don't know how to say it correctly. But yeah, so you can take it and you can deploy it to Vercell if you want, or put it in a Docker container and put it on fly.io or railway or whatever you want to do. But we definitely want to create like a happy path for folks who want to deploy their hydrogen site on oxygen. 

DAN_SHAPPIR: So effectively you have built a Vercell in-house. That's what you're saying. You've got hydrogen as your version of Next.js. You've got oxygen as your version of whatever Vercell calls their servers and edge functions and whatnot. And then I instead, and if my focus, if my primary focus or one of, or an important focus for me is, is e-commerce, then instead of doing it on Vercell, I can do it on Shopify with hydrogen and oxygen. 

JOSH_LARSON: Yeah, for sure. Yeah. be a little bit more generic and support such a wide use case, both in Next.js, but also their deployment tools in Resale. And so Shopify can take those ideas and build a hyper-specific thing, like you said, to something that's more focused on commerce. 

DAN_SHAPPIR: And what functionality does Oxygen provide? So is it servers? Is it edge computing? Is it like Lambda functions? Is it CDN as well? What do I get? 

JOSH_LARSON: Yeah. It's serverless servers, whatever it's, it's edge workers. We're partnering with cloud flare initially at launch to run store fronts at the edge of course, CDN is included with that. We have a Shopify CDN that we've been obviously operating for a while. And so that is, that's tied in with deployments and yeah, I think the big goal too of oxygen because you could go take it, like I said, deployed anywhere, but then you have to worry about all the DevOps stuff. We want to take away all those things and make sure that you don't. You just don't have to worry about it. Like you push up some code, you get a preview link, you share it with your colleagues, and then you merge it or click go public or whatever you wanna do. 

CHARLES MAX_WOOD: That's nice. And yeah, having used Netlify myself, I haven't done as much with Vercel, but those features are terrific. And they're, especially if you're dealing with non-technical folks that need or want to see what you're doing. So that's awesome. One question that I've kind of been still chewing on a little bit as we've been talking about this is, so I'm a JavaScript developer, right? So what does all this have to do with me? Maybe my company doesn't use Shopify or we've talked about some of the technical details of what you've built, and that's very interesting, right? But at the end of the day, why am I going to be worried about oxygen or hydrogen? Are we talking about just career opportunities or consulting opportunities, or is there more here that JavaScript developers are going to want to dive into other than just that it's cool. 

JOSH_LARSON: The lesson of this is it's cool. Now, I think that has a big role in it, right? It's interesting to watch platforms like Shopify pop up with their own offerings, their framework offerings and hosting offerings. I would guess that we won't be the last to do so. And so as a JavaScript developer, I'm curious about what products will I be asked to build? Who's looking to hire? I imagine a lot of folks are going to be hiring JavaScript developers with Shopify storefronts. But what else is going to happen in the future? What else, you know, what other, what is the future of commerce? How does it integrate with these, these new frameworks and hosting runtimes and all this stuff, along with like the, the other part of, of hydrogen that I think I'm excited about as a developer is the, the idea of server components and how does this pattern play out? How does it form into a, like a final version? Does it hold up against the other things? Do other frameworks adopt this same pattern? I think that's what I'm paying attention to right now as well. 

CHARLES MAX_WOOD: Makes sense. S

DAN_SHAPPIR: So just, you know, from the perspective of completeness, like do you handle things like if I upload an image, do you like optimize the image for me? All stuff like that. 

CHARLES MAX_WOOD:They turn it into an NFT. 

JOSH_LARSON: Yeah, all images get converted to NFTs. Super taxing on them. No. Yeah, so I think it's it's really wild to look at the scope of the Shopify platform too because you know You can upload product images those get hosted on the CDN and the CDN supports Transformations like you described and we we have an image component in hydrogen that lets you pass in the mentions that you want And where you want it cropped and the CDN takes care of that So it's something that's technically it has been doable for a while But creating these abstractions in the form of hydrogen components now make it easier and more discoverable

DAN_SHAPPIR: So basically what you're saying is that in a lot of ways you've been able to leverage the existing infrastructure that you've already had in the context of Shopify, be it the CDN or handling multimedia and stuff like that. And obviously the storefront API, and now just giving it a new facade that's targeted at let's call it the way that Chuck referred to it as JavaScript developers, but really the more accurate term would be react developers at this point in time. 

JOSH_LARSON: Yeah. Yeah. Currently with our, our version one for sure. And that's not to say that we haven't changed anything or improved anything about the Shopify internals or features that aren't just facades. I think in the last year, our, our API development team has done a lot of work to improve the ergonomics of our storefront API that we had, we had honestly kind of neglected a while because we were so focused on improving other parts of Shopify that things like being able to pass a product handle or a product ID to grab the GraphQL instance of a product instead of having two separate query roots or not roots, but fields for that. Stuff like that, paper cuts that they've spent a lot of time working on improving the API. So it's just kind of nice that they're all culminating in a big general availability moment here. 

DAN_SHAPPIR: Now, one more thing that I wanted to ask is more or less my final question, I guess. I saw that currently at this time, you more or less have like one theme or demo theme that's associated with hydrogen. Do you like expect to see the evolution of some sort of a marketplace, of additional components, of additional themes? How do you see the ecosystem evolving around this? 

JOSH_LARSON: That's a great question. It's already, we've already had some internal debates about it and we've been super intentional not to call them themes because I think our approach, at the start at least, is that these things should be custom storefronts, completely custom the template that we offer today when you create a hydrogen app is a reference and not necessarily a theme. I don't know if we will someday see like a theme store or some sort of even like a gallery or something like of other reference implementations that people can easily spin up. Maybe that will be a thing. Maybe we will see more no-code solutions like you have in the other part of the Shopify online store in the liquid storefronts with all your your levers and fields that you can tweak. Maybe something like that exists in the future that integrates with hydrogen storefronts, which would lend itself to more of like a theme store. But I don't know. That's a good question. 

CHARLES MAX_WOOD: All right. Anything else that we want to dive on here before we start talking about PIX? All right. Well, this is really cool, Josh. Before we head into PIX, which is where we shout out about all the other things that are cool, that aren't hydrogen or oxygen. If people want to know more or maybe you're hiring on your team, anything like that. Where do people find out more? 

JOSH_LARSON: So yeah, find out more about Hydrogen. You can visit hydrogen.shopify.dev or shopify.dev in general for DevDocs. And you'll find links to our careers there. You can, yeah, check out that documentation site. We have links to lots of cool videos and getting started guides and all that stuff.

DAN_SHAPPIR: And like I said, the StackBlitz integration is really awesome. It's really a great way to get up and running and trying out stuff really quickly and painlessly. So yeah. 

JOSH_LARSON: It really is. And it's so cool. I love StackBlitz. It's so cool what they've built there. Having all that stuff run in a browser is amazing. And it's amazing to even from a maintainer's perspective to see an incoming issue or have someone ask you how to do something. I just type hydrogen.new in my browser and then type some code, change it, click save and share the link. And it's just it's amazing that you don't have to spin something up and clone it and push it to a repo and all that stuff. It's it's going to change the game for sure. 

DAN_SHAPPIR: So is Shopify going to buy StackBit? 

JOSH_LARSON: Oh, man, that'd be pretty cool. I don't have no comment on any of that, but yeah, they're a really cool company. 

CHARLES MAX_WOOD: I'm going to send that whole clip to Eric. All right. What does that include? Yeah, including the no comment, right? All right, let's go ahead and move into pics. 

 
Hi, this is Charles Maxwood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases just taking their career to the next level, you know, whether you're beginner going to intermediate and immediate going to advanced, whether you're trying to get noticed in the community or go freelance, I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go and figure out what the next steps are. And then from there, we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching. 

 
CHARLES MAX_WOOD: AJ, do you wanna start us off?

AJ_O’NEAL: Home Depot online has the muscle rack shelves are on sale right now. Well, maybe they won't be by the time this airs, but I got a few of those for the garage and they're pretty easy to set up and they make it a little bit easier to hold stuff. So I'll pick a muscle rack shelves at Home Depot cheaper than at Lowe's. They're at the muscle rack shelves at Home Depot or cheaper than the Lowe's brand shelves, and I didn't get the Lowe's brand shelves because Lowe's was out of them. And then other than that, I've got got a really controversial pick. So there's a new documentary. Well, it's kind of a mockumentary. So it's put out by Matt Walsh called What is a Woman? And I thought it was hilarious because he's so deadpan when he's interviewing people asking really simple questions and getting really, really convoluted, complex answers or just no answer at all. Do you think it could have been a little bit more? I mean, I think it was created for entertainment value. I don't think it was created to change anybody's mind about the politics of the day or anything like that. I have a hard time believing that that would have been a motive behind this. But it made me think it would be interesting to see somebody take that same approach, but maybe be a little bit more intellectually curious, or I don't know what the right phrasing would be. But I mean, it's apparent that he created it for entertainment. It'd be interesting to see someone do a similar thing, but not take it from the entertainment perspective, but take it from the, okay, where are these people on both sides of the table and, and where, you know, where are they, where are they coming from? And what is it that, that they're really driving at? Cause I think the questions he asked, a lot of them were maybe on point, but the, as some of the interviewees remarked, the tone kind of just put things off. And I think if you had somebody that's more there's this one YouTube channel that I've, I've taken a liking to actually don't remember what it is, but this guy, he, he recently went to an NRA conference and just, just talked with people, just asked them and he wasn't, he wasn't trying to be comedic, he didn't try to catch them in their words or, you know, show them that their, their points were non-logical or contradictory or anything like that. He just went up and talked to people and asked them questions. And it was a really good format of just eliciting, okay, what do people think? And not trying to then, you know, oh, here's the trick question that comes up next that twists your arm. But anyway, so there, is long winded enough? 

CHARLES MAX_WOOD: Yeah, definitely. I watched it too, by the way, and I enjoyed it. I thought you could tell that with certain people who's looking for certain kind of answer and they did not disappoint. The flip side is, is that I think some of these conversations need to happen because what I'd like to see is I'd like to see people understand each other's points of view better as opposed to just throwing rocks and 

AJ_O’NEAL: because that's kind of what I see on both sides is I don't I don't see it a nice okay let's discuss this honestly but then again the part of the debate is that there can't be an honest discussion 

CHARLES MAX_WOOD: because I think that was part of the point he was trying to make the documentary too but at the end of the day that's kind of what I'm hoping for is that we can you know come to understand each other even if we don't agree so anyway Dan do you have some picks? 

DAN_SHAPPIR: Yes I do. So if our listeners listened to our previous episode, my understanding is that you interviewed Matt Pocock about TypeScript. And the reason that it's my understanding is because I wasn't there. And this is kind of amusing because I'm the one that invited Matt in the first place. Now, the reason that I wasn't there was because I was actually traveling. So for two weeks, first I attended and spoke at JSConf Budapest, which was excellent. It's so great to have a real world, real face-to-face type events and conferences again, like returning to normalcy in that extent, it was really awesome. By the way, the MC of the conference was Tejas, who we've had on the show. He was an excellent MC. It was lots of fun, lots of great talks, and also my talk. And in any event, I enjoyed it a whole lot. And by the way, the videos have been uploaded, so probably you know, put a link to those in the show notes, but just go into YouTube and search for JSConf and you'll find them. Obviously, I spoke about web performance and Core Web Vitals and whatnot, but it is what it is. And funnily enough, Matt was actually also there at the conference. So you might ask, why is it that he was able to participate in the show and I wasn't? And the answer is that right after the conference, my wife and I went on a vacation together in Europe. We drove from Budapest through Slovakia all the way to Poland, Krakow, and this has been our first real vacation in almost three years. Because again, Corona, COVID kind of, you know, scattered all our previous plans and it was so great to be on vacation again. I can't even describe it. So if you've been avoiding taking a vacation because of COVID or any other reason, I highly recommend that you do take a vacation and take some time to unwind and relax. And oh yeah, one more pick is that I've started watching Stranger Things, the latest season on Netflix, only episode one, but so far so good. So I'm hoping for the best for the rest of the season. And my final pick will be the same pick that I pick every time, which is the ongoing war in Ukraine, which just keeps dragging on and on. Hundreds of people are dying and effectively on a daily basis. It's so terrible. And what can I say? I really wish it would end, even though it doesn't look like it might happen anytime soon, unfortunately. Anyway, those are my picks for today. 

CHARLES MAX_WOOD: All right. I'm gonna jump in with a few picks then. So I need to pick another board game and I'm gonna pick one of the legendary expansions again. And the one I'm gonna do this time is the Fantastic Four. Legendary expansion. It's not my favorite one actually. I like a lot of the other ones better I've been picking those but it does have characters that have interesting abilities what you'll find with some of the Some of the expansions is that some of them you really want as many characters as you can get from the expansion to fight the villains from the expansion and if you don't have that then it makes it a bit harder and I would prefer that they all kind of have I don't know so that you can play around with having multiple expansions. You can bring in all the characters from all the expansions and have a reasonable chance of actually winning. And this one just doesn't quite play out that way. Board Game Geek has its weight. So for our guests, I always pick a board game. The weight is the complexity of the game. Most casual games clock in somewhere just under one, or just under two, sorry. So like Monopoly and stuff is 1.9-ish. And then, you know, like your Settlers of Catan and stuff are a little bit higher than two. And so this one's a 2.46. So, you know, again, Legendary and all of the expansions are kind of designed for the casual gamer. And anyway, so these, this is a lot of fun, but yeah, that's the, that's one that I like. It's just, it's not typically the one that I pick. I typically go for the World War Hulk, which I think I've already picked and Dark City and the Spider-Man one. So anyway, I'm going to pick that. I guess I should also just shout out one of the ones that I'm probably not as likely to pick, and that's the new Mutants one. I didn't really care for that expansion a ton. Sometimes I'll mix it into one of the other ones to see if you can get some interesting play out of having the different heroes line up, but anyway. So yeah, so those are my picks. Things are kind of heating up as far as top end devs go. So I'm getting the conference schedule finalized like tonight. We're inviting speakers already for Rails Remote Conf, which will be in August. We'll also have DHH. I know that's not this show. It's RubyRogues. But we're ramping up. So we're probably going to do JavaScript, React, Angular, and Vue through the end of the year, the beginning of next year. And then I'm also going to be putting on a Top End Devs Summit that'll probably be in October. And that's going to be more focused on career. So it's the seven points of Top End Devs career. So it's how to learn something new every day committing code every day, meeting new people. I'm trying to remember all of them, going to community events, posting content, all of that stuff that kind of helps you show up in the right places and learn the right things so that you can advance in your career. And ultimately so that you can achieve whatever goals, lifestyle that you want, right? That's ultimately what we're about here. So anyway, I'm gonna pick those and then there was something else. Oh, I'm starting to get into TikTok. And so if you're interested in TikTok, I did set up a top end devs account. I've also been doing a lot of videos for the school board race that I'm in, uh, running as a candidate. So, but it's been really fun to record videos and kind of get some of these ideas out there and start talking about them. So, uh, go follow top end devs on TikTok. It's top end devs and keep an eye out for those videos that are going to start coming out pretty quick here. And that's pretty much it. Josh, do you have some picks for us? 

JOSH_LARSON: Sure. I have, I have two pickS It's the Incredibles and the Incredibles 2. So I have a two year old. Those are fun. And that's what we're watching these days. We start with one and go to two and then go back to one and go to two. 

DAN_SHAPPIR: I consider the first Incredibles to be one of the best superhero movies of all time. 

JOSH_LARSON: Isn't it so good? It's great. And it holds up to a ton of repeated viewing. 

AJ_O’NEAL: One of my favorite moments is when she's feeding the baby and making facial expressions cause that's what people do.

JOSH_LARSON: Yeah, yeah, 

CHARLES MAX_WOOD: I've never made fun of my wife for doing that over 

JOSH_LARSON: It's I think it's cool so I think Incredibles came out in 2004 and the second one came out in 2018 so there's a 14 year difference But the timeline of the two movies there's there's no there's no downtime It it picks up right where the last one right off and I just am so impressed that both the storytelling and the visuals hold up with such a huge gap so It's a good two movies. If you haven't seen them, go watch them. No, that's, that's what my picks are. 

CHARLES MAX_WOOD: Awesome. And then just one more time. If people want to follow up with you, uh, follow you on Twitter, GitHub, check in on the project. 

JOSH_LARSON: Yeah, for sure. JPL Homer on Twitter and get hub everywhere. Yeah. Check out hydrogen. It's it's open source on GitHub Shopify slash hydrogen. And yeah, give it a, give it a spin and let us know what you think. Look forward to getting the project launched and seeing what everyone builds with it.

CHARLES MAX_WOOD: Sounds good. All right, folks, we're gonna wrap it up here. And until next time, Max out. 

DAN_SHAPPIR: Bye. 

JOSH_LARSON: Thanks guys. 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y.com to learn more.