React Remix with Ryan Florence

0:00Remix is a full-stack, open-source web framework that was developed by the creators of the popular React router library. It focuses on features such as server-side rendering and efficient data loading, and it emphasizes developer experience. Ryan Florence is a co-creator of React Remix, and in this episode, he speaks with Josh Goldberg about the Remix project. 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 ES Slint, the tooling that enables ESLint and Prettier to run on TypeScript code.

0:38Josh 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 Blue Sky, Mastodon, Twitter, Twitch, YouTube, and.com as Joshua K. Goldberg.

1:07With me today, back to the podcast, is Ryan Florence. Ryan, welcome to Software Engineering Daily. Thanks for having me. Excited to be here again. Yeah, we've been looking back at your old interviews, and you've talked about a lot of really cool stuff on the show, and we're going to dive into a lot of cool stuff today. But before we get into the wonderful world of Remix, can you tell us a little bit about yourself and who you are? Sure. I'm Ryan Florence. I live in Utah and I've been doing web stuff since the beginning of the web really. My dad invested in an ISP when I was a teenager back in the mid 90s.

1:41Then I started doing websites for customers of theirs. One of them was a plastic surgery before and after photos thing. And as like a 16 year old, that was like, that was not something I wanted to work on. But anyway, yeah, I've been doing web stuff for a really long time. I remember when CSS was invented. I remember the Jscript versus JavaScript thing with Internet Explorer and Netscape and Mozilla before that. But anyway, and then more recently, what most people probably know me by is React Router and after that Remix. So I was a co-author of both of those along with my career partner, Michael Jackson.

2:20He and I have been doing stuff together for over a decade now. So yeah, love working with him. He's brilliant and just awesome person to work with. And so it's been fun working on all that stuff. That's what people might know me by. And I love playing guitar. Oh, you can't see it over there. And just music generally. Same with Michael. That's why the Remix brand has so much music stuff with it. And snowboarding and soccer and raising kids. I got three of them. So that's me. I just connected Remix as in River Remix. that's what the connection is? Yeah. Yeah. Remix. Amazing. Just curiosity. Do you ever look back at all the advances in the web and feel some sense of positivity or optimism about how far it's gone since you started?

3:05Oh man. That's sort of like looking at your teenagers and like, sometimes you feel like, wow, we nailed it. We did such a good job raising these kids. And there's other times you're like, where did I go wrong? What did we, what did we do to mess this child up so much. And the web definitely feels that way to me where it's like, sometimes it's just incredible. I mean, the fact like what we're doing right now in Riverside FM, we went to a website, right? We open up a browser. The first browser that I ever used, links was just in the terminal and it just sent you text. It was, it was hilarious to where now I punch in Riverside FM slash whatever this idea is.

3:46And now we're, we're streaming and uploading and communicating in real time with like, what, probably 20 milliseconds of lag between when I speak and when you hear it, that blows my mind. Yeah. So it's incredible what we've done with the internet and with browsers in particular, that web tech can do this. The financial models aren't there for a lot of the things. I think that's the thing that I lament the most is, you know, we got WebGL. We could have, you should be able to go to eldenring.com, and start playing Elden Ring. We have technology in the browser that should make that possible, but we don't have that, I think, primarily because of financial models where it's pretty much just ads.

4:27E-commerce is like the, what do they call it? That's the killer app of the web, right? E-commerce is the thing that I think the web is clearly the best at. You can just go and shop and buy stuff. and then uh but everything else it's kind of it's it's hard to just always do ads to make money so app stores and stuff you make a really coincidentally good segue you mentioned that you co-authored remix and react router y 'all were in some way acquired by shopify could you tell us what what the actual thing that happened was yeah we were we were acquired by them so how does that worked though for an open source project to now be owned or acquired by a company?

5:08I don't think it's different than others except for that we had no revenue. No, we actually did. We actually sold Remix at first. Our first model was selling licenses to use it. So it was open source, but you had to pay to use it. So we actually did have some revenue. Yeah, we had been building Remix. We raised some VC money. We're building the framework. And then always in the back of our head was like, well, then what's the business model? At first it was licenses, but we always knew that we were going to graduate past that and do something else. So do you build services on top of it? Do you do hosting like, you know, Next and Vercel?

5:44That's how most VCs thought of us. Like that's what they all wanted us to do was build a platform like Vercel on top of Remix. Anyway, so we had a bunch of ideas about what we were going to do. And then we saw that Shopify was building Hydrogen, which had a lot of overlap with what Remix was doing. And Kent C. Dodds at the time was working with us. And he reached out to them and was like, hey, we have no particular thing we want to pitch you on or anything. But we're both building similar things on top of React. Let's talk. And so we learned about Hydrogen. They learned about Remix. And from there, it just eventually ended up with them saying, hey, how about instead of having to come up with a business model, you know, we raised some VC money, but that'll run out.

6:25So instead of worrying about your business model, how about you come and just build Remix at Shopify? and essentially Shopify funds the development of Remix and we just build it under their roof. So it's really fun because of course, it's fun to build products and stuff, but our heads were just in Remix for the most part. And that's what we wanted to work on, or at least that's what I wanted to work on. Yeah, so you sign some papers and make a deal and then they send you a work laptop. And off you go. Yep, and off you go. How would you have described Remix, let's say two years ago? Just know that the follow-up question is going to be, how would you describe Remix in six months from now or a year from now?

7:03That's making me just think about what are the differences now, but I think I would still describe it the very same way that I worded it on our website. I don't have it memorized. I'm going to go look at it. Focused on web standards. Yeah, it says Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience. I think that's how I described it four years ago. That's why I would have described it two years ago. I would describe it now as I would just say, instead of Remix, I would say React Router.

7:35Yeah. Let's talk about that, actually. React Router, the router, or one of the big routers for React. Before we go there, I do want to talk about what changed after we got to Shopify with Remix. Remix was very much, I don't know if server first is the word, but server required. It always server rendered. You always had a server. you always had to deploy either a Node or a Cloudflare or a Dino or Bun server. So we had the whole full stack JavaScript thing going on. I always like to say center stack because some people, when you say full stack, think, where are your queues? Where's your database arm?

8:08Where's all this stuff? And it's like, okay, we're center stack. We cross the gap, but then you get to do whatever you want on those sides. Anyway, so it's very much started with a server. When we got to Shopify, there's a handful of things. They don't just build e-commerce with their framework, Hydrogen, on top of Remix, but they're using React Router everywhere. So React Router is like when you log into your store. If you are a merchant, that's a React Router app. If you are in that admin interface, you can add what we just call apps, third-party apps, where maybe someone can create a shipping tracker app that you can add to your Shopify store.

8:46and those are just like one-click installs for a merchant and those apps are hosted on you know they're built by whoever this app provider is but then they're integrated into the admin interface so that a merchant you know has a really nice cohesive it's sort of like an operating system for your your store everything's right there you don't have to go log into someone else's thing to like work with your shipping stuff you can just do it right there and so those third party apps, we had some templates for people to use React Router. So there's this kind of big push, like, hey, how can we adopt Remix in more places?

9:20And that actually pushed us to soften up the server requirement. And we brought a lot of the abstractions from Remix over into React Router directly so that you could do things like define your data for the page for your route, define the actions for a route. But instead of doing those things on the server the way that we did in Remix initially introduced these concepts of client loaders and client actions and they would just run in the browser and then we even got rid of the server requirement where it could just run as a full-blown spa with no server or server rendering at all and so that helped get a lot more remix adoption too where people like i don't actually want to run a javascript server but i do like the way that you organize code and remix with loaders and actions and getting access to all those pending states when those things are pending so you can build a nice user interface.

10:11That's the big difference that happened from before we got to Shopify and then now is we really beefed up the flexibility of how to deploy a Remix app. You don't have to have a server. Yeah, I remember when the static HTML feature started going into, I think it was beta or however you call it. That was very exciting. There's been a lot of back and forth on the web over traditionally it was called MPAs, multi-page apps versus single-page apps, SPAs. Not the most helpful delineation these days. It's all fuzzy, but I think we all generally now agree on what we mean by SPA. Yeah. Are there particular architectures that you think Remix is moving more towards or away from?

10:52Or do you see like a next set of steps in Remix React Router's future for that? Let's go back to the, what's happening with React Router? And then I think we can get to that question. Your questions I'm always going to keep putting at the end of the stack and then we'll pop them off. Yeah, so after all that work, we realized, the question you just asked me, though, is do I think that Remix has a specific architecture that it lends itself toward more than others? Is that kind of? Yeah, I'm just curious, your perspective on what are the right way or set of ways to work with Remix if there is such a set?

11:24Yeah, is that a cattail I see walking back and forth? It is, he's a very needy cat. I was like, what is that? And I was like, oh, that's a cat. Actually, I think I can speak to both things at the same time. So the short answer is no, I don't view Remix and React routers having a preferred architecture. React router is actually really old in web years. You know, like you think about CSS was created 22 years ago, I think. So it's like CSS. Like I think kids today probably just kind of assume that has existed forever, right? I remember when I realized that the beetles weren't like a thousand years ago.

12:03I was like, oh, wait, the beetle, there are beetles who are still alive. Like that, that just blew me away. Remember I was like a teenager. I think that's the way CSS is for some kids where it's like, oh, that's, it's not that old. It's only like 22 years old. React router is 11, 10, 11 years old. So it's half as old as CSS itself. So this project has been around for a long time, and React itself has always been super flexible, too. We've always been able to server render React from the beginning. Most people didn't, but it was always there. You could run it on mobile and React Native. It's always been a very flexible thing.

12:39And React Router has always tried to support the great flexibility of React. So when Remix added a bunch of server stuff, right afterward, React itself did too with React server components and server actions. And then they introduced a bunch of things like use action state and use optimistic and use transition. All of those concepts, all of the use cases for those things in React, we had like a cognate over in Remix already. So it's been kind of tricky for us to figure out like, do we deprecate our stuff? We just go straight to that stuff because there's like 90 % overlap. If you have like a task, which API are you going to use?

13:21With React getting more involved with the server and with transitions, being an old project, we want to support that and those new models of how to deploy a React app with the assumption of a server like React server components. But we also have to recognize that we've got a decade of highly successful apps still running React Router without servers like that. Like right now we're in Riverside FM. It uses React Router, but it doesn't use any of our server features and it doesn't use any of React server features either. And so we're not just going to bail on that paradigm. It's a successful paradigm.

14:00Linear, which is an app that everyone talks about all the time as being kind of like the pinnacle of web UX with local first and doing a data sync. They use React Router and not using any of our async stuff like loaders and actions. They're just using the components that match URLs and then the components and hooks that let you navigate around and read state from the URL. So we're not going to go like say, oh, we think you definitely need to have a server to run React Router, we would not be serving the user's needs that we've had for the last decade by doing that. So while I think that there are some new architectures that are novel and interesting with server components, there's just no need to bail on what's currently working.

14:47So we got linear on one end of the spectrum. ChatGPT.com is a remix app, but most of their data loading is done with react query instead of react routers loaders or remixes loaders and actions but what it does use is the root loader for like user information and other kind of other things like that and so that's really useful now you navigate around you don't have to worry about overfetching all that stuff again they get the bundle splitting that remix provides on their routes, but they aren't using the data loading pieces. And then you've got Bolt.new. I don't know if you've messed around with that AI.

15:26Oh my gosh, it's so cool. Go to Bolt.new and try it out. It's one of those AI things where it's like you just described the app or what you're trying to do. And then like it does everything. It makes files, it refactors them, it can write tests, it does tons of stuff. And that's a full-blown remix app using lots of our features. So I kind of like where we're at of not saying this is the blessed architecture because at shopify alone we have very different use cases and they're all using react router or remix and yeah there's i just you can like tacos and you can like burgers you don't have to say burgers are the only best fast food right and so like we can be a single team building a single project react router and it can support multiple paradigms and architectures and deployment strategies.

16:14And I'm happy with that. I'm happy to hear you say that. There's been somewhat of, I think, a misconception at large in the React community the last year or three that React was going all in on server, that server components were the one and only way. And that is an area of investment for sure. But there's nothing stopping you from, as you said, making a Riverside or ChatGipity style, you know, single page or somewhat single-ish page app. You've also brought up a lot of really interesting words like root that have meanings in the Remix React Router world and context. For those who haven't used Remix or React Router themselves, could you give us a brief overview of what some of the really important concepts are if you're writing an app with them?

16:52Yeah, so I'm just going to throw this in here really quick. We moved everything from Remix over into React Router, which really was just our bundling and a couple of server concepts. And so now you can really say Remix and React Router interchangeably. But moving forward, React Router v7 has everything that Remix had and more. We'll talk about this later in the show, I'm sure, what we're going to do with Remix after this. Now I'm just going to talk about React Router. Because everything that was in Remix and wasn't in React Router already is now in React Router v7. So yeah, I said root. And then there's the word route.

17:26And if you are from certain parts of the world speaking English, you say those words the same way. and so you can have a root route or a root root. So let's see, where should we start? First thing is URL, right? That's how websites start. Here's a URL. So we call that anything that's going to match that URL and then render something, we call that a route. And so you can nest these routes below other ones so they build on the path of their parents. They also build on the UI of their parents. There's this idea of an outlet where it will, I guess, yield the content of the child route inside of the parent route.

18:01so it makes layouts really easy. That was kind of like our bread and butter for the last 10 years. The root route, it has no URL. It just always matches. And you can put things like loaders on there that say, hey, here's all the data that I need for this route. And if it's the root, then that's kind of like the core data of the app, like who's the user, what are their preferences, what A-B test are they in, or whatever, right? But every one of those routes down the tree can have their own data as well. And it will go and fetch that data Or simply just call your loaders in the browser to get the data handed to the component and the component can render.

18:36So it's kind of an MVC model where, you know, you've got model view controller. We have no model. The view are React components. And the controller is these two functions called loader and action. In the case of a spa, it's client loader and client action. And those loaders decide what data to then give to the component. So instead of splitting a model view controller at like a flat layer at the top, you get like little nested MVCs for each route inside of there. And then if a form is submitted or you do it with code, it'll call the action on that route, which can run on the server or in the browser or whatever you want.

19:14And after that action gets called, instead of you having to then go find the new data and like set some state and react to then update the page, We just know automatically that if you did something that calls an action, then the framework will automatically go and say, well, I knew how to fetch the data originally. I'm just going to go and fetch the data again. And then the page will update automatically. So it gives you that old school PHP feel of, you know, here's a page, here's a form, mutate some data, forward to the right back to the page that you're at. And then your code just runs again and gets all that data.

19:48the behavior as a single page app, even though a bunch of your codes are running on the server, where it's just using React to update just those parts of the DOM. Did I go off on too many tangents or is that what you were looking for? That's very much what I was looking for. Thank you. Yeah, you bet. Are there other topics or parts of React Router you'd like to go into before we move on? I don't think so. No. All right. So we've talked a good bit about where things came from, the fact that you've been purchased by Shopify or acquired by Shopify. I would love to get your take before we talk more about the future of React Router.

20:22Where does React Router end and Hydrogen begin? Or I guess, really, what is Hydrogen and how does that fit into the React Router vision? Yeah, so if you're a merchant, you want to set up a store. If you have no technical ability, which is most of them, you don't care about React or React Router or Hydrogen or any of that stuff. you just pick a template from the Shopify interface and go from there. And then we have this thing called Liquid as well. So if you're technical, you can get in there and customize your store with Liquid templates. But there's this other version of e-commerce. Some people call it headless.

21:01So headless e-commerce. I think we just call them custom storefronts, where it's like, I'm not going to use your templates. I'm not going to use your Liquid stuff. I just want to use the API to my store. So Shopify has a very capable API for everything about your store, get all your products, get all your collections. So you still log into Shopify and manage your store through the Shopify admin interface. But you can then write code to talk to our APIs to build your store, the actual interface that people go and visit. And so Hydrogen is a way to build a custom storefront. So instead of just saying, all right, here's our API, knock yourself out, shopping carts are actually a little bit complicated and all the variants of a product and how can I render a 3D model of the product that I'm trying to sell you, where will I get a component for that or just the image components, all that kind of stuff.

21:59So there's a lot to think about and efficient sorting and queries and stuff like that. So Hydrogen is, I guess you can think of it as like a utility belt that works well with Remix. So they got their own CLI to scaffold a custom storefront. So you can just be like, I don't know the exact command, but like Hydrogen new. And then it scaffolds out a store for you. From there, you own all the code. You can go customize how it looks and everything else. And then there's a bunch of abstractions to render your cart. like you know when you go to the cart page and it's got all the line items and they got abstractions for buttons to increase the quantity and see it see it optimistically update instead of waiting for the network request yeah just just a lot of like it's like a utility belt of like well if you're going to build a custom storefront here's a bunch of stuff and you're probably going to want some of it and then a cli and things like that to make the the full development process nice specifically for building a store it makes sense then that shopify would be interested in being able to fit that together with the underlying meta framework for react so to speak that you have a vision of the architecture of your app that can be assumed or worked with nicely by the the stuff on top yeah yeah uh it was kind of fun when we went to shopify people like oh great now remix is just going to turn into an e-commerce thing it's like no no there's that's what hydrogen is remix is still independent of that shopify has just been incredible i've loved working here they told us before we came, they're like, hey, we're not going to like, we're not going to tell you what to do and stuff.

23:30We want you to just build the best React framework that you can. But we want you to listen to our teams, right? Like we want you to take their feedback and help that shape what you build. But by no means are we like, going to be held accountable for like, oh, the hydrogen team wants this. Why didn't you ship it? And now we pretty much have tried to do everything that they've ever asked for that would make their lives easier. But they've let us operate very independently. And it's been great. They definitely kept their word because you never know, right? I never worked at Shopify. I'd never talked to any of them.

24:03And they're like, yeah, come and work for us. Your company that you just built and you've put all your blood, sweat, and tears into. And so you kind of worry, how much autonomy am I still going to have with this thing? They've given us tons of autonomy. They're just awesome, awesome company. Yeah. I think one of the signs that a framework is being given the autonomy it needs is that is able to invest in areas that don't directly obviously contribute to whoever's controlling the money. And actually, I did want to bring up one area. If you go through the currently Remix docs, there are a lot of notes here and there about how something is not supported in the classic Remix compiler, but is now supported in the Remix Vite build engine.

24:42What is the difference? Or can you tell us about this move to Vite that Remix has done? Yeah, when Michael and I started Remix in the throes of 2020 lockdowns, Vite didn't exist. Webpack, Webpack's a great project. It was a little bit slow though for bigger projects and stuff. And ESBuild was in beta. And ESBuild was fascinating because it was so dang fast that it was like, we don't even need the concept of like a dev server. Save a file, just build the whole app again. And it was basically fast enough for that. I remember stress testing stuff when we were before we had released anything. And I made an app with like two and a half thousand routes.

25:30I worked on a Rails app. I worked at a company called Instructure. We built Canvas LMS that a lot of people might be familiar with. It was a Rails app. And he said rake routes. You had two and a half thousand routes in that app. So I kind of picked that is like, well, if I can't build Canvas LMS all in Remix, then with this compiler, then like, it's not going to work. So I did that. And it was too slow for my liking. And then after I profiled it, it was all my code that was too slow. But ESBuild was plenty fast. Classic. Yeah. So anyway, we made a bet on ESBuild. This is fast. And the thing that I liked the most about it is that with the classic Remix compiler, dev and production only had one difference.

26:18And that only difference was minification of your code. Other than that, it did all the exact same things. There's nothing that irritates me more in the JavaScript world than when it works in development, but it's broken in production or when it works in production, but it's broken in development. And so I've always really valued keeping that gap like as narrow as possible of what's my dev build and what's my production build. So that was the motivation behind picking ES build. We started to want to do HMR, hot module replacement, so that as you save a CSS file, you don't have to reload the whole page.