EPISODE 1710

[INTRODUCTION]

[0:00:00] ANNOUNCER: A headless software architecture decouples the front end, or the head from the back end. This separation allows developers to manage the UI layer independently of the backend logic and data management. Hydrogen is Shopify's open-source headless framework for building custom storefronts. It's React-based and is focused on performance and flexible UI components. Ben Sehl is a Senior Product Lead at Shopify, where he works on Hydrogen and the storefront developer experience. He joins the show to talk about his engineering background, the motivation for creating Hydrogen, Hydrogen versus the liquid templating language, and much more.

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on BlueSky, Mastodon, Twitter, Twitch, YouTube, and .com as Joshua K. Goldberg.

[INTERVIEW]

[0:01:21] JG: Ben, welcome to Software Engineering Daily. How's it going?

[0:01:23] BS: Hey, Josh. Great. Great to be here. Thanks so much.

[0:01:26] JG: Oh, thanks for hanging out. You've been doing quite a lot of interesting stuff in and out of Shopify. But before we get into all of that, could you tell us a little bit about who you are and where you came from in tech?

[0:01:36] BS: Sure. Yeah. My name's Ben. I am a senior product lead at Shopify. I work on all things to do with the storefront developer experience is the best way to sum it up. The biggest thing I've been working on over the last couple of years has been a framework called Hydrogen, which is a way to build storefronts with React. How I got into tech, if I go all the way back, I come from a very technical place in the world. I grew up in Waterloo. I went to the number one math high school in the country, showed it to WCI. Everybody in my computer science class was the kids of people who worked at Blackberry.

Got a lot of exposure there and just always was fascinated with technology. Honestly, I was somewhat off put thinking I was bad at it compared to everybody else. Then they all went to start huge companies. I ended up in design and worked in Toronto for a number of years. Then I moved down to New York and worked at a startup there. Then things didn't turn out with that company. At that time, I ended up starting a new company and skipped about a decade. Now I'm here at Shopify and back into the tech world. That company was in apparel. Yeah, there and back again and yeah, now doing all things here.

[0:02:55] JG: That's a lot of work in and around dev and storefront tooling. Is there anything in particular that brings you to managing, or supporting storefronts?

[0:03:03] BS: Yeah. I think, actually, started really when I was in design. It didn't matter if I made my designs pixel perfect. In the time, I was using Photoshop. Something always got lost in translation when I sent it to developers. At some point, I figured I'd just learn CSS and do it myself. The more that I got into it, the more I learned. Initially, when I was building websites, I used these different visual CMSs. They were super easy to use, but they generate this garbage code. I just never liked that. Actually, when I was working at that startup in New York, I created this side project for the time to I just want to make a better white T-shirt.

I was working with my then fiancé, now wife. She came from a fashion background. When I got let go of my job, I actually applied for a role at Shopify as a theme designer and didn't get the job. I figured, okay, I'm going to build this thing as a custom liquid theme. Then I'll reapply and I'll have this proof point on my portfolio that I can do this job. Yeah, so just never reapplied until eight years later. But I did the calculation, because as of next month, it's been 10 years working on the stuff. I think I've done a little over 30,000 hours in storefront developer tooling, just thinking about it and obsessing it, but as a user and now, as a shaper, I guess, is the best way to frame it up.

[0:04:29] JG: That's honestly two really good points to touch on before we go into Shopify. One is that you can apply for a company after having been rejected earlier on. In your case, you are now quite high up in the company and this is not your first time trying to get in. The second is that it's really powerful for people who work on products to have used the products first, right? It gives you a lot of introspection and understanding of the user experience.

[0:04:52] BS: I think, actually, those are the - if you have a job that you want to get into, those are the two most important things you can do. It doesn't matter what role you are. If you're using that thing, you're going to be more insightful about the product than a lot of people. The easiest way to get an advantage at a company is to be obsessed with that company. So many brilliant people I work with are coming here from context that this is the first time they're working in commerce. Maybe they've done high-up jobs at Google, or whatever, but they just don't know this domain at all. You get a huge advantage if you are just obsessed.

Then the other one is, yeah, if you get rejected, who cares? Just keep applying. That's just going to only show a positive signal that you really want to work there. So much of the best people that I work with are just the ones who want it the most. Like, who actually wakes up on a Monday and is excited. Those people are the ones that are just the best possible people to be on your team. A great signal for that is, yeah, you just keep applying and keep going for it. It doesn't matter if you get rejected. That's actually fine.

[0:05:56] JG: Absolutely. You talked a little bit about what you were doing before, and you used a term 'liquid'. Could you tell us what Liquid is?

[0:06:04] BS:  Yeah. Okay, I'm going to have to do some historical work here that I learned as somebody who's doing a bit of loss in translation, but Liquid is a templating language that our founder and CEO, Toby, created to enable people building on Shopify to make fully custom storefronts. Shopify, for anybody not aware, came out of also a pretty crazy thing. Toby had made the snowboard store, and then he realized the tech behind it was more valuable, and then they turned it to Shopify. It was a way to summarize a lot of time and work into a very small amount of words.

I think I remember hearing this thing that initially, he even started with a CSS Zen garden approach of, hey, maybe you can just allow people to write CSS and tweak stuff and then realize, "No. I want to give people more control." Instead of saying, "Oh. Here, write your own Rails controllers, or whatever," he created this language, Liquid, which would allow you to fully customize the markup, but in a secure way.

Part of the beauty of Liquid, why I fell in love was I came from building all these WordPress sites, and the first thing you're doing is CH mod commands on the WP config file, and then moving to Liquid and the first thing I do is write product up title and the title just shows up. It was this incredible thing where I felt like, all of that to use a term board from the Oz team, undifferentiated heavy lifting is just removed from me. I got to just focus on what made my brand unique. I just felt like, huge superpowers and oh, my gosh, I can do so much more than I used to working with this tooling. I fell in love right away. Then eventually, ended up exploring a bunch of different technologies, but that was a gateway drug for me to get into the whole world.

[0:07:53] JG: Sure. There's a parallel there where Shopify was founded quite a while ago now, based on, in part, being able to have a really, really solid dev experience for folks building shops, as you've described. Now fast forward to year 2024, that's still a big differentiator for Shopify. Can you tell us a little bit about what you've been doing, or what the company's been doing since to keep being on the forefront in that area?

[0:08:15] BS: Sure. 20 years is a lot of time to cover. But yeah, I think Toby being an engineer himself, I think really cares about that. Technology is, I mean, this is a crazy thing to even be having to say in 2024, but technology is just like a part of everything now, right? I think when you were starting, probably people would have said, why is Liquid even necessary? Just eBay, how are you different from eBay? How are you different from any of these other companies?

There's merchants like Allbirds that started our platform and have scaled to become public companies on their platform, that's not a unique story. A lot of these awesome companies bring on developers over time. I was a developer myself who started a company in my mother-in-law's basement. I also wanted to code and I - the thing with websites is like, when you're starting a company, it's like, how many domains do you own that you don't have companies for? Because you have this idea first, and then you probably make this website, this landing page where there's a teaser and then eventually go and build this product.

It's probably not the way you should do it. It's just that the way excited people build things. People really, really love it. This is their home on the internet. There's so few things that you own now, right? You own your email list and you own your website. These are the two things. Shopify has always been a company that, for the longest time, you probably didn't even know about, even though you were shopping on us. We've always been trying to lead from behind and help the supporters of our merchants and not the stars of their show. That's something about, I don't know, maybe because I'm Canadian, but something about that I have always loved, too.

I think, I'm on a bit of a retention now, and I've forgotten where I'm going. But that's just always been the key in giving you more ability to have that home on the internet be exactly how you want it, I think, is what a lot of the driving force was for that.

[0:10:13] JG: Side note, I did not know Allbirds was started on Shopify.

[0:10:15] BS: I might be making that up, but I'm pretty sure that's the case. I think they actually started as a Kickstarter, and then it then became a Shopify store. Yeah.

[0:10:24] JG: Shout out Allbirds, by the way. Fantastic shoe brand. Incredibly comfortable.

[0:10:28] BS: Very comfortable shoes.

[0:10:30] JG: Shopify is, among other things, really emphasizing hydrogen these days. Can you give us a primer on what Hydrogen is and how that compares to the liquid templating language?

[0:10:38] BS: Yeah. Hydrogen is one of the ways that we give you with Shopify in order to build storefronts. For a long time, we gave you Liquid. Liquid is still an incredible framework, for lack of better words, to building your store. It's incredibly high leverage, and you can really make beautiful custom sites. I was just talking to a friend about glossiers, It's an awesome example of a completely custom, every single pixel of that thing has been combed over storefront that's built using the Liquid templating language.

Hydrogen is the opposite end of one very specific key tension, which is server control. The main differentiator, obviously, besides being React-based versus Liquid-based, is that Hydrogen is a tool set for building what are called headless websites. Headless just means, you're grabbing the API from somewhere. Historically, as many, you're also hosting it on your own. Though, we give you this thing called Oxygen, which is also a runtime hosting platform designed to pair perfectly well with Hydrogen. You can go and deploy these things. We actually host it for you, or give you that option. Then Hydrogen is a framework for building these things.

Actually, as a merchant myself, I first built a liquid storefront, and then eventually, I did go and build a headless site. I did that, because I just started to hit these different constraints of the platform that I felt at the time anyway, I could do more easily just tapping the API and using React. Then I went and tried to do that, and I saw that actually, there were some great pros, and I love React. There were also a ton of cons. On liquid, you type product, price, bar, money, and you get the product price in a money format, contextualized to the buyer that's seeing your site in any currency around the world, and dynamically at the right time, with right discounts applied, all this stuff.

In React land, tapping the various APIs to do that, this is hundreds of lines of code, right? There's just so much. That thing that I said I loved about Liquid, pre-Hydrogen, in headless world, there was just so much undifferentiated heavy lifting that I had to do in order to become productive. Then not only do you have to do it upfront, but you have to maintain this. Your APIs are changing, and sort of this stuff, too, so it becomes a total mess and nightmare.

A huge part of Hydrogen was really an answer to that. My core aim was the easiest roadmap when I first started was, well, I know Liquid really, really well. Here's everything that Hydrogen currently can't do out of the box. Let's go close all those gaps. Then, let's do it in a way that you still get complete control, and you also get control over the server. It's built on top of remix. That server control piece is the key, and that's the reason why some teams just love React, and that's cool, and that's great, but there is teams like ButcherBox, who are built on Hydrogen. You go to their site and they don't have collections, they don't have products. You build a box of meat. Their product is a slice of bacon that you add a bunch of different slices of these bacons, and you add other types of meat, and then you get this custom box and you subscribe to it.

They have a custom subscription app that they built and all these sorts of things. The standard models that we have for Liquid just didn't really make sense for them. Now, if they were to go and do that, that way, they were also coming from a React-based custom stack, switching on to Shopify. Hydrogen just made a ton of sense. Then enabled to just do that so much faster than if they were to just roll the realm for everything. Yeah. That's really why Hydrogen's there. I think it's the opposite end of, I like to think about these key tensions. But then, we keep a lot of the same principles and philosophies and try and bring the two worlds in terms of capabilities closer together.

But again, there's a ton of benefits to not having server control as well. We can make your site super performant. Snowdevil.ca is still running 20 years later, like doesn't need any code changes. It's backwards compatible. It's only gotten faster over time, right? As I said, you only have to do product dot price and you get all this stuff. You don't have to worry about fetches and authentication and data orchestration and any of that stuff. Yeah, I'm rambling now, but that's the key differences between the two.

[0:14:56] JG: Sure. Another aside, snowdevil.ca, interesting site. This is a Shopify demo store that has not broken in the past 20 years.

[0:15:04] BS: This was what Toby's store originally was. This was before there was a Shopify, there was Snowdevil. Snowdevil started as actually, Toby moved to Canada to be with his now wife, Fiona. He couldn't get a job, because visas wouldn't allow, but you could start a company. Government policy would allow him to live here if he had a branded company. He started this company called Snowdevil. He loves skiing in Whistler and different places, right? Yeah, they started Snowdevil, selling snowboards. As legend has it, it was summertime. You're not selling as many snowboards. You're like, "What are we going to do now?" Meanwhile, he's pretty big in the Rails community, and so things spun up there. Anyway, he should join the podcast to give the full story, but that's the legend of Snowdevil.

[0:15:46] JG: The legend of Snowdevil. I also really like how you phrased 30 seconds ago, there are those two, I'm going to say, blended different motivations here. One is giving people pixel perfect control, but then there's also making it so you don't need to specify pixel perfect control to have a working site. For example, you alluded to earlier how you would have designs in Photoshop and then there's always something lost when coming to the web. Do you think that long-term folks are going to continue to have those two different motivations as they keep trying to build on hydrogen?

[0:16:19] BS: I don't know. I think some people don't care, and some people do care. For me, as somebody building it, and even as somebody who was using it on the outside, it probably didn't change anything, but it changed my pride when I was building with Liquid, that I knew that the code that I was shipping, I wrote and I was proud of. Even now, I mean, I use GPT and stuff to write a lot of code, but I'm still shaping it.

I think it's just woodworking. You just care what joints are used. It's more of a pride in the craft. As long as you can deliver that craft without compromising on the value that people are hiring, or firing your product to do, then why not do it? I think we will get into more and more declarative interfaces as we go, right? There's going to be a lot more of that thing, but certainly, anything I want to put my hands on, I want to make sure that I'm super proud of everything down to the bolts, and that if anything was generated, it's generated in a way that I would do it myself.

[0:17:34] JG: I want to ask you a few technical points of interest, because it is fascinating to watch a company build such an agnostic, or generalist stack, while still keeping to the principles of quality code, the woodworker craftsmanship angle. How do you integrate with other tools that power folks like you and me, developers would use, like CI/CD systems?

[0:17:53] BS: Sure. Yeah. We have a product principle here overall, which is make the important easy and everything else possible. I think that applies especially true to Hydrogen. It applies to everything, but certainly in our world, the reason people are going headless in the first place and giving up on a ton of value that Liquid gives them is because there's some constraint in the business that they have to make a pretty big investment in order to accommodate for, or at least believe they need to. Fundamental upfront was anything that we make with Hydrogen, like the developer has full control over everything. We are there to help accelerate them, but we are not there to put hindrances on them.

There were some things that were coupled to GitHub in their early days, but now are decoupled and you can use whatever CI/CD you want, whatever version control system you want. Then we just go deeper on certain platforms. We do know most of our users most of the time are using GitHub, and so we have a one-click integration with GitHub that sets up CI/CD for you automatically and has all this nice stuff built in. That's true for a number of different areas. We're very careful when we put abstractions on things.

We did some work early on where we made things really simple, and then we'd get folks, like ButcherBox, who I mentioned that would have all these different edge cases that would then clutter up the API design, and so I try to make accommodations for. We took another go at a lot of those things and have learned to be cautious and want to still strive towards making things as simple as possible and productive as possible, without boxing you into anything. Yeah, you own the code. It's all open source, right? We keep all of our discussion out in the public and have our community members weighing in on our tickets and PRs and discussions and all that. We post RFCs for any new feature that we do, so we can involve people really tightly. I talk to people building on our platform every week to keep that in there.

Then we run our own stores on it, too. Hydrogen is actually what powers additions, which is our biannual marketing event that summarizes everything that's been up for the platform. That's actually behind the scenes. Well, it's not a store itself. It's a marketing site. It's actually modeled as a storefront and uses all of our tools. I run a side business on Hydrogen as well, where I get to dog food everything that we're doing and get feedback. Those feedback loops are really vitally important, while keeping some of those core principles in mind upfront just on, hey, why did we do this in the first place and who's it for? Let's not compromise that, because we're not trying to be the one tool either. The awesome part about hydrogen is it gets to lean into what it's doing, because we have Liquid, and Liquid can lean into what it's doing as well. There's these two awesome ways to go and tackle the same thing. Yeah, it's a pretty unique position to be in.

[0:20:48] JG: Yeah. It's really interesting to see, as you go lower down in the stack, things become more generalist, but then they have a little more needs of user configuration. Remix is fantastic as a server side and front-end framework, but it's not customized, or it's not particularly specialized for storefronts, or marketing sites. It's just a generalist framework.

[0:21:07] BS: That's right. Yeah. It's funny, actually, initially, when Hydrogen launched, we were our own framework. Actually, under the hood, it was the main three components were VRSC and react router. We ended up at one point, doing our own router for different reasons. Then we pivoted on to Remix. Now, they're evolving with react router seven. We're going back to V plus, react router plus RSC, but in a much, much better way where we've learned from all over the past mistakes, and it's a very stable transition to move there. That should create a thrash.

A huge thing for us was when we were building our own framework, we realized, hey, we're putting in all this time to doing all these low-level primitive things that aren't really specific to commerce. That's detracting from our ability - you're trying to boil the ocean a little bit, right? It's very hard to make a lot of progress. Then if we were to go build on a different framework, you are aligned, until you're not. Then once they want to do something that you don't want to do, "Well now, uh-oh." How money, what roadmap stuff can we share with them? How much context, internal context can we share?

Then, when we got the Remix team to come and join Shopify and be on board, that was really this opportunity to say, let's solve for some of these challenges we've had. We are super, super early in React Server component world and things were really not stable there at the time. We knew we wanted to have that technology bake for a while before we could really move forward with it. Remix had a lot of this solved for a lot of the same outcomes that we wanted, but in a much more stable API, so we really loved their philosophy, loved how they use the platform, really embrace the web. Overall, very small surface, API surface area relative to what you can build with them.

By joining them, we could say, "Hey, let's align everybody, so that they can get all the context from all of Shopify." Not just Hydrogen, but you can build apps on Remix, right? We build our internal, all of our internal apps and stuff are now built using Remix. You have the full context of the full company going into refining this framework. Now, our teams can build these meta frameworks on top of them that can really make them more purpose-built tools. We can do it in a way that aligns with the philosophy as well. A huge thing, when you're first shaping this building on top of Remix, Toby made this analogy of Ruby S versus Rails evangelists, and it being two quite separate camps, even though it's both Ruby, right?

We wanted to make sure that what we were doing with Remix really complemented their philosophy. If you built a Remix app anywhere, you could just add Hydrogen on top of it and just immediately get Shopify functionality onto your site. All of the Remix docs need to be true when you use Hydrogen, all the tools that work with remix need to work with us. Obviously, we have oxygen, which is a runtime that's used as workers, so you can't use any node package necessarily. But you can also host Hydrogen wherever you want.

That was a very, very, I think, a pretty massive unlock for us and what enables us to really do a lot moving forward. As with somebody building a product to that huge, huge businesses, or building on top of, one of the key things, too, is they want to feel in control, right? These are massive companies that are making big bets to power their technology. They don't want to necessarily say, "Hey, let's use some sort of stack that's only possible on one specific vendor." You can use remix with whatever you want. If you want to, like, I don't know why you'd want to leave Shopify, but if you wanted to go somewhere else, you can bring your Remix app with you. There's nothing Remix specific to Shopify about Remix. It's just that we can align with them super, super well and make sure that everything is possible. They get that really, really tight. I just keep seeing aligned, alignment all the way through the stack. That what makes it feel, again, to use the word working analogy, really dovetailed and fit nicely.

[0:25:07] JG: It is really a shame that corporate shenanigans have ruined so many great phrases, or great words. Alignment really is a powerful concept and framework design that you're very much using.

[0:25:19] BS: Yeah, whatever. I'll lean into the jargon. That's fine. I like it. It's still a good word. They won't steal it from me.

[0:25:26] JG: Another reference here I want to pull in. There's a great Mark Twain quote, "I didn't have time to write a short letter, so I wrote a long one instead." You've had so much company investment at work and engineering thought go into making these frameworks as small and composable and jam-packed as possible. Do you feel that over time, although things are getting smaller in size, such as the foundation of building on Remix, they're getting more and more composable and higher quality.

[0:25:52] BS: Well, what an interesting use of that quote. I reference it all the time. I've never thought about this. Yeah, I think so. There is so much about Shopify that's continuing down that line. We have things, like functions. I'm going to get outside of my ears that I don't know enough about, but functions allows you to not only have some composable microservice part of the cart. It's not for that. There's lots of companies that can do that. But now you have a network request buy latency to your whole business. Functions allow you to have that composability and change how our business logic works, but run the code in WebAssembly right next to our servers, so it all happens in real time with virtually zero latency. That's a massive, massive unlock.

We have meta objects and meta fields, which are our words for custom data, so that you can put any shape of data depending on - regardless of how your business is modeled. We can fit that shape of data into our platform and you can relate commerce objects to it, so you can say this product has these fields on it and they relate to these other objects, which relate to whatever. You can do that while syncing with CMS platforms, like Sanity. Sanity's CMS can actually sync its data into meta objects, and then you can query all that stuff through our one storefront API. You don't even need to have a mesh API or back end for front end, or any of that stuff. It's all just unified.

I think all that DNA in terms of really obsessing over the craft and trying to achieve these outcomes, while not only not compromising on performance and code quality, but actually, doing in a way that improves it over what we had before just comes from really, Toby, and his obsession over craft. I was thinking, he's just like, you can only be this long as a founder of a massive company if you are just obsessed with the domain itself. It can be the only thing driving you.

Yeah. Certainly, I think, analogy I thought about a lot before joining Shopify, which is that Shopify is this connect foreboard, where commerce is just a massive domain. Each level of complexity of business is like a row in this connect foreboard. Each column is a different thing, whether it's shipping, or payments, or logistics, or modeling your products, hosting your platform, whatever. To run your business on the platform, we have to fill up all the columns and all the rows to your level of complexity, because we can't miss it. We can't miss a beat. We can make it more composable. We can have the APIs that link into these different systems, and that's one great way to do it. If you want to do it all in one, you have to build it all into the platform.

I think finding that right mix is pretty interesting. I think that's one of the things that Shopify does really uniquely well, where other folks either try and become a monolith, or everything's a microservice. You really lose a lot when you have to make that distinction. We have a different approach that I think allows for the best of both worlds there. You can have infinite flexibility and customization without the downsides of, I mean, I don't know, anybody who's had to work with a web of microservices can just know like, if you want to pull one thing, you're pulling a million things. Yeah, there's a lot of really interesting things there. This just goes so beyond my depth technically. That's why I'm a PM and not an engineer. It's a very cool place to be in a cool moment in time to be seeing this stuff really come to maturity and also, be able to look into the past when I wasn't at Shopify and sees, "Oh, okay. How did the nascency of these things begin and where did they evolve to? What does that tell us about the future?

[0:29:53] JG: You alluded to these as a DNA, or the traits that work well together. I quite like that analogy, that a lot of these advances are in response to a threat, or a response to a difficulty. Setting up, going from I have the desire to make a store to a URL. That was a hard experience. Now, it's much easier. Let's say, the hydrogen headless stack. Is there any particular next threat, or difficulty, or challenge that you think you'd be interested in challenging, or taking on as a team?

[0:30:22] BS: Yeah. I mean, these things continuously evolve. It's very hard to say anything too long term. Maybe, I'll put it this right. Hydrogen is two-years-old. Now, we are evolving super quickly. We have tons of folks on the platform. Just the scale that you can get into at these types of companies is crazy. We have a huge responsibility to make sure that everything's really stable. We also have this incredible ability to co-build with them. I said, we're open source, and so, we get a lot of insight from them.

We keep our roadmap fairly tight, just because things do change so quickly in the web and just technology overall. There are four main goals that we continue to push on forever. Really, one, this is like, Shopify storefronts is the fastest platform in the world. That's for running a storefront. That's true on Liquid. There's this website called ismypostfastyet.com. You can check it out. Shopify is number one, and we have been for a long time. There's a lot we can do better, right? We can have better documentation, better educational material to help you build, write faster code. We can have smarter defaults. We can have better toolings, so that you can find optimizations in your performance.

Then the second is having the best developer tools to allow you to get more done with less. Liquid was why I fell in love with the web, really. Hydrogen, we're trying to really do as good of a job as I can possibly do to provide an alternative to Liquid when that makes sense for folks. I ultimately want both of those to be incredible developer experiences, so we'll continue to invest there.

Then the third, as you mentioned, is infinitely flexible, is key for both stacks, right? We want not only for those to be flexible, but also, to be have the ability to act on that flexibility easily. That also means, having a really large partner ecosystem with first-class integrations. A lot there, but to recap, that's performance, productivity, flexibility, and integrations. Those are a continuous source of places to draw from in terms of how should we be shaping the platform and where along those axes are we excelling, or we have opportunity to push things further.

One of the key things for hydrogen right now is the main gap left open is visual editing. Liquid has had this thing we call the online store editor for, I don't know how long, but seems like forever. It is amazing, because as we mentioned before, that, hey, I want to be able to customize my site, but I don't want to jump up the code. How do you manage that? Well, this visual editor, the online store editor with Liquid is how that's really been done. It allows you the ability to have your whole team come together and manage the website visually. Other great tools, like Webflow and there's others that are out there doing a pretty good job of this, too. Hydrogen hasn't really had that, at least from a first-party perspective.

Now, we've just announced the Hydrogen visual editor, and that's going to be a huge area of focus for us in the future. Really making that a place where your entire team can come and collaborate in real-time to affect change on your website. That's quite huge for us. Doing so in a way that doesn't compromise on any of those things that makes hydrogen what it is, which is you can use the exact workflows you want, you can bring all your own tools, you can tap different CMS providers and third-party APIs and PIMs and whatever. That's really a huge area for us that we'll continue to shape. Then there's a number of other areas, but that's probably the biggest one to dive into.

[0:34:12] JG: I'm very interested in the visual editor direction. The front-end community still hasn't come to a full agreement on how to write styling systems for the front end. On the one hand, you have things, like Tailwind, which are very quick, but not super type safe. On the other hand, you have bigger things, like Panda and Louie. How do you feel about this whole area of being able to write front-end styles in a visual editor?

[0:34:37] BS: Visual editor. Yeah, I could talk for three hours about design systems and CSS, because I've thought so long about this. That's actually one of the areas that you really get to rabbit hole on as somebody who's building on top of the platform and not the platform itself. There's so many different approaches. I think you're all fantastic, to be honest with you. So long as they don't add runtime overhead. But this will be something that we'll really, really want to dig into. I have a lot of thoughts. There's a lot of things that I'm keen on in terms of developer ergonomics here. There's a lot of great prior art style system. We've got to give them a shout out. What vanilla extractive sprinkles and recipes have done, it's super interesting.

Tailwind, I love. Uno CSS by Anthony Fu is fantastic. There's a lot of really, really interesting approaches. It's whatever, I think, gets the job done in a way that you really love. I'm a big fan of utility classes to be with you. Ultimately, we got to back up. I think this comes down to like, how are you prioritizing developers versus non-developers and how are you making this thing happen? This is a meta question behind the question, I think. To me, I go, like, anytime I'm getting priorities from when I'm talking to devs building our platform, or non-devs, I really try and do the five why thing.

I have a toddler who interrupted us, but try not literally ask five whys, because that does get annoying. The common thing for all of the folks building on Shopify, ultimately, is typically, where we all unite is that we want to make a better user experience for people shopping on these storefronts. That ultimately ends up translating itself into to better conversion rate. I'm not a massive fan of growth hacking overall. I think focusing on the long-term and customer experience is the right way to do it. Then when you look into the tooling, we have - conversion is basically four things. There's motivation, like, what are you optimizing for? What do these people want? Value proposition? Are you able to communicate that properly? These are marketing challenges.

Then there's the negative side, which is like, anxiety, right? Is it going to ship to me? Is it going to fit me? What do I do? Can I return it easily? Those are all things that developers can't really action. Then there's friction. I think friction is length-related friction, difficulty-related friction. How easy is it to shop on my website? Once I want something, how long does it take to get it? That's really where we try and tackle. That's, I think that then when you bubble that up, friction is also how fast is my team able to ship things that help reduce this, or help us improve conversion overall? There's friction there, too.

Where we've really been trying to improve developer productivity, removing friction in their process by killing boilerplate, giving them better developer tools, allowing them to figure out how to solve problems faster, we haven't yet done a great job at solving the handoff between those designers and developers. I said, way back to the beginning. That was really the crux of how I got into development in the first place was I always wanted my designs to look a certain way and I could never get them to do it. I learned code and lots of other folks can't necessarily. That's really where, again, where the Hydrogen visual editor comes in is we want to lay that foundation for the future of collaboration, and we want to build a space where the whole team can collaborate in real-time and directly manipulate any part of the website.

How does that translate into CSS? That's something we got to duke it out and figure some things out there. There are some great escape hatches, right? We do have in-line styles and stuff like that. Because there's version control, you can make small diffs, so that devs can quickly refactor into their framework of choice. One of the things I love about React is props, right? I think that I loved about style system was design props.

I think the key for me is when you can tie, create a design system where these style props can actually match to the editor itself. When you can do that, you can create UI to be able to tweak these things in ways that you actually like in your code, and it's not littering it up. You can then create types where you can put constraints on what are people allowed to do and this sort of stuff. You don't just put a thing, a product part on a page and you say, "I allow you to tweak any border radius you want, to be anything that you want and hit save and it goes live." You can actually say, "No, no, no. You're allowed to select from these options as defined by our creative director, or whatever. You can hit save. Then even when you hit save, it goes to version control and we have to approve it, and can put it in whatever workflows we want."

Long would it answer there, lots of tangents to probably dig into. I think for us, it's like, we always got to focus on what's the core thing? We're trying to remove friction for teams overall, so that they can ultimately make better commerce experiences for their customers. There's so much to unpack and dive into. One of those really, really narrow things is the design system. It is a meta, a big meta web of problems related to solving team collaboration in a way that ultimately, you ship code that you're super proud of and that you would write yourself. Do call that way in the beginning.

[0:40:18] JG: There is a beautiful callback here, a nice circle in your life where you started off, as you said, with the design developer handoff. Now, you're again starting to look at among other things, the design developer handoff.

[0:40:29] BS: I guess, I just got bit by this bug and I just can't shake it now. It's the only thing that I care about my entire - Like, what am I going to do with once this problem gets solved? That's what I'm really having an existential crisis about. It's like, once we - I'm determined. We're going to be the ones to solve this problem. Once we solve this problem, I'm going to have a real talk with my therapist, or something to figure out what the heck is next. Because maybe there's no end game and it's just endless, endless tinkering in design system land. That would be totally fine by me, but it's a fun space to play.

[0:41:02] JG: In our last few minutes together, I want to talk a little bit about things that are still fun, but not quite in the space. Before then, are there any other points you wanted to bring up on Hydrogen, or Shopify, or other technical areas?

[0:41:12] BS: Too many. I think there's too many things. I can't even go down that road. We're just huge fans of the web platform. No matter how you want to build, we want to give you the best tools to do that, so you can ultimately do the best work of your life and create incredible commerce experiences. We're just having a lot of fun. I mean, if folks are thinking about joining Shopify, or building on Shopify, or building for Shopify, it's a really, really, really fun future ahead, and there's so many different great avenues to go down. That's my spiel and my plug. What are you thinking about?

[0:41:52] JG: Well, Ben, I wanted to ask you. If you were a Mario Kart character and kart combination, which one would you be and why?

[0:41:59] BS: Okay. Well, here's the thing. I'm obsessed with Mario Kart. My Mario Kart character is Dry Bowser. I sadly forget which motorcycle I'd choose, because it's always locked in. I remember it's cyber slick wheels, because I don't know why. Which one would I be? Well, I live - I think I do reflect my city choice. I live in Toronto. I have this analogy for cities, which is, I think of every city as a different Mario Kart character, and Toronto to me is Mario. I never choose Mario, because Mario is just sevens across the board. For an individual race, it's not who I want to pick.

When you're living in Toronto, it's like, I really love the well-roundedness of sevens for a place to live. I lived in New York as well. New York is ultimately Dry Bowser, for sure. Max top speed, minimal handling. If you wipe out, you are done for. That is really where you then turn to San Francisco for your max acceleration, which is Yoshi, right? Every city really maps to these, but who am I? Oh, man. Yeah, it's like a weekday 9 to 5, I'm Dry Bowser. Personal life, I'm Mario. Maybe Baby Mario, actually. I don't know.

[0:43:14] JG: For those who haven't played, you've described Dry Bowser, Mario and Yoshi. What is Baby Mario like in Mario Kart?

[0:43:20] BS: It's just like, I'm even more Mario. It's the exact same characteristics as Mario, which is the opposite of Dry Bowser. Just cute and innocent, well-rounded.

[0:43:31] JG: Well, that's all the concept we have time for. Ben, this was fantastic. Thank you so much for joining the show. We talked about everything from design systems and Liquid and Hydrogen to you being a Baby Mario.

If folks wanted to learn more about you and/or Hydrogen on the internet, would there be anywhere in particular you want them to go?

[0:43:49] BS: Sure. I'm @BenjaminSehl on X. It's S-E-H-L. You can check out hydrogen.shopify.dev to learn more about Hydrogen. Go check out our GitHub. You can use NPX Shopify Hydrogen in it. I think we'll finally be working to create a new project and start playing with it. Yeah, send me your feedback. I'm keen to get some hot takes.

[0:44:11] JG: You're asking for hot takes on the internet. You're a brave person, and it's been an absolute pleasure to know you.

[0:44:15] BS: Yeah, come at me. Come at me.

[0:44:18] JG: For Software Engineering Daily, this is Josh Goldberg. Have a great day, everyone. Cheers.

[END]