← Software Engineering Daily
Software Engineering Daily
React Remix with Ryan Florence
00:48:36
Remix 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.
Loading summary
Transcript67 lines
- [00:01]
Josh Goldberg
Remix 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 ES Slint 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 dot com as JoshUakGoldberg.
- [01:08]
With me today back to the podcast is Ryan Florence. Ryan, welcome to Software Engineering Daily.
- [01:13]
Ryan Florence
Thanks for having me. Excited to be here again.
- [01:15]
Josh Goldberg
Yeah, we've been, 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, but before we get into the wonderful world of remix, can you tell us a little bit about yourself and who you are?
- [01:27]
Ryan Florence
Sure. I'm Ryan Florence. I live in Utah. 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. Then 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. Anyway, yeah, I've been doing web stuff for a really long time. I remember when CSS was invented. I remember the Jscript vs JavaScript thing with Internet Explorer and Netscape and well, 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. And I've 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.
- [02:49]
Josh Goldberg
I just connected. Remix as in remix. That's what the connection is.
- [02:54]
Ryan Florence
Yeah, yeah, Remix.
- [02:55]
Josh Goldberg
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?
- [03:06]
Ryan Florence
Oh 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. And now 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, we could have. You should be able go to go to eldenring.com right 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. Like that's the only E commerce is like the. What do they call it? That's the killer app of the web. Right. Ecommerce is the thing that like I think the web is like clearly the best at. You can just go and shop and buy stuff. But everything else, it's kind of. It's hard to just always do ads to make money. So app stores and stuff, you make.
- [04:48]
Josh Goldberg
A really coincidentally good segue. You mentioned that you co, wrote, co authored, Remix and React router. Y'all were in some way acquired by Shopify. Could you tell us what the actual thing that happened was?
- [05:02]
Ryan Florence
Yeah, we were, we were acquired by them.
- [05:05]
Josh Goldberg
How does that work though, for an open source project to now be owned or acquired by a company?
- [05:09]
Ryan Florence
I don't think it's different than others. Except for the. 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. You know, 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. Do you build services on top of it? Do you do hosting? Like you know, Next and Vercel? That'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. 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, we raised some VC money, but that'll run out. So 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. Sounds 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.
- [06:55]
Josh Goldberg
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?
- [07:04]
Ryan Florence
That'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.
- [07:13]
Josh Goldberg
Focused on web standards.
- [07:14]
Ryan Florence
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, that's how I described it four years ago. That's how I would have described it two years ago. I would describe it now is, I would just say instead of Remix, I would say React Router.
- [07:36]
Josh Goldberg
Yeah, let's talk about that.
- [07:38]
Ryan Florence
Actually.
- [07:39]
Josh Goldberg
React Router. The router or one of the big routers for.
- [07:42]
Ryan Florence
Hang on, before we go there, I do want to talk about what changed after we got the 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 Deno or BUN server, you know, 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 form, where's all this stuff? And it's like, okay, we're center stack, we cross the gap. But then like 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 in it. 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 you know, maybe someone can create a shipping tracker app that you can add to your Shopify store. And 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 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? And 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 are like, I don't actually want to run a JavaScript server, but I do like the way that you organize code in 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. That'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.
- [10:23]
Josh Goldberg
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.
- [10:42]
Ryan Florence
Yeah, it's all fuzzy, but I think we all generally now agree on what we mean by spa.
- [10:46]
Josh Goldberg
Yeah. Are there particular architectures that you think Remix is moving more towards or away from? Or do you see like a next set of steps in Remix React Router's.
- [10:56]
Ryan Florence
Future For that, let's go back to the what's happened 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, like a specific architecture that it lends itself toward more than others? Is that kind of.
- [11:17]
Josh Goldberg
Yeah. I'm just curious your perspective on like what are the right way or set of ways to work with Remix if there is such a set?
- [11:24]
Ryan Florence
Yeah. Is that a cattail I see walking back and forth?
- [11:27]
Josh Goldberg
It is. He's a very needy cat.
- [11:29]
Ryan Florence
His name's Joe. I was like, what is that? And I was like, oh, that's a cat. Actually, I think I can. I think I can speak to both things at the same time. So the short answer is no, I don't. I don't View Remix and React Router as having like a preferred architecture. React router's actually really old in web years. You know, like you think about, CSS was created 22 years ago, I think. So I was like, CSS, like, I think kids today probably just kind of assume that has existed forever, right? I remember when I realized that the Beatles weren't like a thousand years ago. It was like, oh, wait, the Beatles. There are Beatles who are still alive. Like that. That just blew me away. Remember, I was like a teenager. I think that's why CSS is for some kids where it's like, oh, 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. And React Router has always tried to support the great flexibility of React. When Remix added a bunch of service 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? Do 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? With 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 like bail on that paradigm. It's a successful paradigm, Linear, 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 the users 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. So 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 ever fetching 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. Oh 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 subscribe 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, 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. And I'm happy with that.
- [16:17]
Josh Goldberg
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 ChatGPT style 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:53]
Ryan Florence
Yeah. 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 server concepts. And so now you can really say Remix and React Router interchangeably. But moving forward, React router v7 is it 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. And 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 any. 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. So 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 AB 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, hand it to the component, and the component can render. So it's kind of an MVC model. Where you know, you got model view controller. We have no model. The view, our 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, we'll call the action on that route, which can run on the server or in the browser, whatever you want 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 were at, and then your code just runs again and gets all that data. The behavior is a single page app, even though a bunch of your code's 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?
- [20:00]
Josh Goldberg
That's very much what I was looking for, thank you.
- [20:02]
Ryan Florence
Yeah, you bet.
- [20:03]
Josh Goldberg
Are there other topics or parts of React Router you'd like to go into before we move on?
- [20:07]
Ryan Florence
I don't think so, no.
- [20:11]
Josh Goldberg
Understanding the details of infrastructure tools matter, and there's no better way to understand that than looking directly at the code. Open source code bases give everyone the ability to inspect, audit and contribute to the software they use, enhancing trust and transparency. Bitwarden is a trusted open source and end to end encrypted security solution that empowers businesses and individuals to securely manage and share information online. Made by developers like you, Bitwarden offers open source solutions for virtually every credential management use case, from secrets management to password management and passwordless. Developers can even securely manage their SSH keys with the new Bitwarden SSH agent. Get started on your open source security journey today and start your free trial@bitwarden.com.
- [20:57]
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. Where does React router end and Hydrogen begin? Or I guess, really, what is Hydrogen, and how does that fit into the React router vision?
- [21:19]
Ryan Florence
Yeah, so if you're a merchant, you know, you want to set up a store. If you have, like, 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. So 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. So there's a lot. There's a lot to think about and efficient sorting and queries and stuff like that. So Hydrogen is, I guess you could 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 optimistically update instead of waiting for the network request. Yeah, 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 full development process nice specifically for building a store.
- [23:45]
Josh Goldberg
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 stuff on top.
- [24:00]
Ryan Florence
Yeah, it was kind of fun. When we went to Shopify, people were like, oh, great, now Remix is just going to turn into an E commerce thing. It's like, no, 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. We 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 never talked to any of them. And 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, so you kind of worry, like, 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.
- [25:08]
Josh Goldberg
Yeah. I think one of the signs that a framework is being given the autonomy it needs is that it's 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 remixed 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. What is the difference? Or can you tell us about this Move to Vite. That Remix has done.
- [25:35]
Ryan Florence
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. I worked on a Rails app. I worked at a company called Instructure. We built Canvas LMS a lot of people might be familiar with it was a Rails app and you said rake routes, you had two and a half thousand routes in that app. So I kind of picked that as 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.
- [26:51]
Josh Goldberg
Classic.
- [26:52]
Ryan Florence
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, and 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 pick an esBuild. 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. We had live reload before so you could save the file and then the browser would automatically reload through a websocket that we built. And that's mostly fine. But then the way Remix works, you got your loaders up top that are pulling stuff from your database or some third party or something. So super annoying for editing CSS and changing styles because every single time you tweak a style and Save you got to go fetch the data again. It just slowed down that part of UI development. And so we started working on HMR team worked on that. Pedro and Mark put a lot of work and Jacob's involved with everything everybody does. And once they got it working, they had gotten to the point where they're like, vite's pretty mature now and we just did a whole bunch of stuff to try to support this. I don't want to put words in their mouth, but my memory of this is that they were like, it works, but like, it's a little bit messy and there's really no getting around to being that messy. We should probably just use Vite because it's got all this stuff built in. And so we switched over to did some experience with Vite. It took us like a year. Like we kind of goofed around with this idea for a year before it was like, yeah, let's go with Vite. And that's been a big deal. It's been very useful for app developers. There's a lot of stuff that we don't have to do anymore as the remix team. We don't have to build our own compiler anymore, we don't have to build our own HMR CSS stuff. Like all the things that bundlers do. You can now just bring in a Vite plugin if you want to get that kind of bundling behavior. And half of our team, I would say the founding half of our team have had it with bundlers and we hate them. And the other half of the team is like, this is amazing. Bundlers are fantastic because they give you a whole graph of everything in your app, right? From assets to JavaScript to icons to CSS. And now we can optimize it all. But I just get super irritated because I can't touch Vite without dev being different than production. Like every time I. Like every time I touch it, I end up with that. And everyone always says, oh no, you work those bugs out and eventually it never matters. But I haven't gotten to that point yet. Personally, I always have a problem. But on the flip side, HMR is really, really nice with Vite React Router dev tools used to be like this weird thing to try to like add it in. It's built by another developer, not on our team. He's awesome alum. And that now is just a vite plugin. So there's lots of really cool things about us adopting Vite, but it's not without its trade offs. I just, I really hate the dev and production are not the same thing. It goes through completely different code paths. Sorry, I'm going to start ranting about it all. I should stop. Sure. It's great. Let me say this. You know, if someone from the Vite team is listening to this, they're like, oh my gosh, Ryan is being a jerk and throwing us under the bus with things. Adopting Vite has been. I still think it's the right choice that we made and they have been incredible to work with. Smart, talented team and yeah, I still think it's a net positive but personally I still run into the inconsistencies that's.
- [30:46]
Josh Goldberg
Part of writing a framework. It's these trade offs I'm also excited to talk about. You've mentioned that it's freed you up to work on things. What are some of the things it's freed you up to work on?
- [30:54]
Ryan Florence
With React Router V7, it's been hard actually to push React router forward. RSC kind of like threw a wrench in everything. It's hard to figure out. I already mentioned this a little bit. It's hard to figure out when your primary dependency React takes over a bunch of the use cases that you are handling. How do you incorporate that without looking like you're just changing the API arbitrarily? Right. Why are you getting rid of loaders? Well, if you want to use rsc, you don't need a loader. But I liked loaders. Why are you always changing React Router? It's like, okay, well then we can just not support rsc and then you get the like, why don't you support all of React? You're a React framework. Why don't you support rsc? Literally we had a hook called usetransition. That's what our hook was called. Use transition to know when something asynchronous was happening in Remix, like calling loaders or actions or whatever. And React now has a thing called usetransition that generally is active when an action, a server action, or a form action is being called. We have our own form component and an action points to your route. And now React has a form action prop that takes a function that when that function is getting called, it triggers the pending states of the usetransition hook. So it's like there's just this huge mess of overlap now where like 90% of what made Remix unique in the browser, in the client part of things, not the service stuff, but the client parts. React now has a version of that. And so we've kind of been Doing two things at once. Number one is just figuring out what the heck RSC is, what server actions are, how all their new transitions and actions and stuff work, how to get it into React Router and to do it in a way that you can mix the concepts, because you got to be able to mix the concepts so that we don't blow away all the work that people put into their Remix and React router apps already. You got to be able to easily move from the loader action paradigm of React Router over into the RSC and form action paradigm of React. Like these things have to be able to work together and otherwise you got to rewrite your whole app. So balancing that along with balancing just the typical spa use case of like Riverside and linear and GitHub and everybody else who uses React Router. Like how do you balance all of these APIs and make them all work together? So it's, it feels like kind of a big thing that's slow and hard to move forward. But React Router V7 is what we generally worked on over the last year. I would say the first year at Shopify we worked on making React or making Remix work without a server. So spa mode, client server, client actions, client loaders, all that kind of stuff. And the vite, the migration over to vite. And then second year has been RSC research and design and moving everything over into React Router so that we can have this multi paradigm framework that lets you use as much of it or as little of it as you want. We're just about there. We're getting close on the RSC stuff with React Router V7. We've got loaders and actions that run on server, we've got client loaders and client actions that run in the browser or just keep on doing it the old way, you know. Here's another thing that we've been able to work on a lot too is better type safety. As I'm very interested in this. Yeah, as TypeScript ESLint guy yourself, this is a topic you're probably interested in. It's difficult. So there's two types of typescript, right? There's like, there's type safety and then there's like all caps type safety. So like type safety is like you just naturally write your code. I take a string here, I take a number here. This thing should be a React node, this thing should be that it's going to return a number and that stuff's all fine and easy. But then like all caps, TypeScript is when it's like how come my links don't give me a list of every possible route that I could go to? How come my, my loader data in my component doesn't tell me exactly what the loader returned? Nevermind. It went over the network and it got serialized. I should still see exactly what that data is. And if I sent an integer of 42 and I said as const at the end of that, I want in my component to know that that is 42. Right? So that's not normal type safety. That's like telling TypeScript about how the framework operates because the type system itself doesn't know. If the loader returns this, then an argument to this export in your module is going to get this value. Like you got to do tricks to know that kind of stuff. So Pedro on our team has done a lot of the work there to get type safety. So we've got really great type safety. Now we have this routes TS file where you define your routes a lot like railsroutes rb. Then as part of the dev workflow you get these. I think they're virtual modules that give you all the type inference for those routes. So we're actually looking at the route paths where you have like patterns with the colon, like colon user id. And it can be optional too. Our typegen there will parse out those dynamic segments of the. Of your route paths. And now inside of your component and your loaders and actions, when you say params. You get a hint that like says, hey, I know that you have a user ID on there because I went and read your routes TS file. And so that's really nice because now you get. You're not going to go try to load data for a param that doesn't actually exist on your. On your route. It also infers the loader data now too. So you return values from your loader. Your component gets a prop called loader data and that thing's fully typed as if you called the function yourself and comes back. Jacob has worked a lot on our transfer format over the wire for streaming thing called Turbo Stream. It does serialization and deserialization of a bunch of different types. So it's better than JSON Stringify. You get numbers back out of there, you get dates back out of there. It's the basis that we're going to do for rsc so you can get components out of there. You know that that couples with the type safety because if you pass a date react router sends it over the wire and it has to serialize it it comes back to the browser as a string, but then react router on the other side of that parses it and then gives you back a date. So all of your type safety is much simpler. You don't have to like assume, oh these are all serialized, they're actually the same values. Even promises. You can even have nested promises and they come all through. Yeah, it's a promise on the back end, goes over the wire and then comes back as a promise in the browser. It's kind of cool.
- [37:33]
Josh Goldberg
Developers, we've all been there. It's 3am and your phone blares, jolting you awake. Another alert. You scramble to troubleshoot, but the complexity of your microservices environment makes it nearly impossible to pinpoint the problem quickly. That's why Chronosphere is on a mission to help you take back control with Differential Diagnosis, a new distributed tracing feature that takes the guesswork out of troubleshooting with just one click. DDX automatically analyzes all spans and dimensions related to a service, pinpointing the most likely cause of the issue. Don't let troubleshooting drag you into the early hours of the morning, just DDX it and resolve issues faster. Cycrosphere was named a Leader in the 2024 Gartner Magic Quadrant for Observability Platforms at Chronosphere IO Sed this episode of Software Engineering Daily is brought to you by Jellyfish, the leading software engineering intelligence platform. AI codegen tools can be force multipliers for R and D organizations, but are you making the most of them? Join your peers on April 17th at Glow Live. It's a dynamic 90 minute virtual event that explores the transformative nature and potential impact of AI CodeGen solutions. At Glow Live, you'll hear expert insights on navigating a constantly shifting landscape, adopting CodeGen tools successfully, and measuring their impact on your team, your work and your company's long term success. Register today at Jellyfish Co Glow and get glowing.
- [39:03]
I like the way that you put it that There are the two levels or types of TypeScript, and I think it's kind of unfortunate that as people go more and more into frameworks such as yourself, like folks who are actually writing the frameworks, they may or may not be the people who also want to write intense deep typescript with words like key of and const and mapped types. But if you have users using it, it's going to be an inevitable thing that they want that level of type safety.
- [39:29]
Ryan Florence
The all caps one and as a as a humble JavaScript web developer who graduated with an economics degree and has never touched a computer science class. It took me a while to figure out that just to iterate over a list of an array or unions or over a union. It's recursive. There is no for each in TypeScript. Generics. Right. It's like if you're writing Typescript code, everything is a recursive function. And so it's like, okay, I know that this is a map. I need to do a map here. And then we got to do a reduce. So, like, I have all the words in JavaScript, but then in. In TypeScript, it's like, it's just a different way to think about code. So it has been kind of fun. Yeah. One time, Michael and I were working on. I don't even want to say it out loud, but working on a new router anyway. We were getting type safety there. It was like six hours straight of writing these recursive functions to try to get the thing that we wanted. And it felt like doing homework. Like, it's like, okay, here we go. What do we need? First we need the loop code, and then we need this. Does this extend that? Okay, here's. And does it extend an empty array? Okay, that means that the left side is one item and the right side is zero items. And so at this point, we do this and then we recurse. And it was just like recursion after recursion after recursion. And I was like, this is. I feel like I'm in a computer science class doing a worksheet on recursion.
- [41:01]
Josh Goldberg
If it helps.
- [41:01]
I have a computer science degree and I felt absolutely unprepared for the Typescript type system when I started using it. I did not think it was something that I got out of university or really wanted in my life at the time.
- [41:13]
Ryan Florence
Did you have the vocabulary, though? Like, when things started to click, you're like, oh, this is like that.
- [41:17]
Josh Goldberg
You know, I think I did at one point in computer science class. And I'm so sorry, Professor Varela, who. I remember being a great programming languages professor and teacher, but no, I. It's. It's one of the unfortunate things, I think that it's just so different from everything else. By the way, I could talk about Typescript for years, as I'm sure you know. But I do want to give you a chance to talk about more react router stuff. And I have one final question on the subject of it. Let's say that we have this conversation again in two to three years. What would you predict to be the Thing that you are most excited about having been accomplished in those two to three years.
- [41:49]
Ryan Florence
Oh, man. Remix V3. I want to call it Remix V45 for the RPMs on a record player, but I think. I don't. I don't know that I'm going to get my wish. So we moved everything over to react router, which 90% of remix was already in React Router. So it's like we moved the last 10% over. So we moved everything over to there. That gave us room to just do something really cool with Remix. We love the Remix brand. We get a lot of flack still on Twitter. We even got a little bit internally of people like, what on earth are you doing? Why are you killing Remix? Yeah, yeah. It's super fun. And we're like, we're not. We're not. We're not killing Remix. I said from the stage, Remix is going to take a nap. Generally, people don't die when they take a nap. They'll come back. They come back refreshed, they come back better than they were before. But we've been dedicated to smooth upgrade paths. And so the best way with the model that Remix was on, of everything being done at the route module level, that was best moved over to React Router and just continue with that paradigm. That's one timeline. And we want to make the best version of that that there is. The analogy that I always use is it's like Chrono Trigger. Did you ever play Chrono Trigger?
- [43:05]
Josh Goldberg
I'd say that I did.
- [43:06]
Ryan Florence
Do you know what it is?
- [43:07]
Josh Goldberg
It's a video game.
- [43:08]
Ryan Florence
It is a video game. Good job. Yes.
- [43:11]
Josh Goldberg
Thank you.
- [43:12]
Ryan Florence
It was a Super Nintendo game built by Squaresoft. Or maybe it was Square Enix at that point. I think it might have been Square Enix. And in my opinion, it was pretty much the best Super Nintendo game ever. It was my favorite one, actually. Every couple of years I'll play it again on an emulator just because I loved it so much. What's interesting about Chrono Trigger is that it came out after Nintendo 64 was released. So you got Nintendo 64 a whole new model. You got 64 bits. You can do 3D stuff. Like, it was just. It was a completely different world over there. And obviously the future of video games was over there on the Nintendo 64, not on perfecting and optimizing Super Nintendo games. But Chrono Trigger was released after Nintendo 64 on this old model. That it was just the best version of that ever. And it is still good today. I still love playing that game. Games today could still learn stuff from, from Chrono Trigger. So for me personally, I'm not going to speak for the whole team here. Everybody on the team works on React Router and has an influence on it. But for me, that direction that we were going with Remix and then React Router is the Super Nintendo, there's nothing wrong with it. And so react router V7 and when we have a V8, like to me that's Chrono Trigger, it's like this is the best thing that we can do with this model. Before server components, before web UIs were all over the place, before React could do things that it can do now, where we basically had this one tool which was the Route module and we hung every API off of Route modules. React has inspired what I think is a new generation of even more encapsulation across the stack for a server component. Server actions and client components. Inside of there you can build a little box, right? And we've seen people making these kinds of demos with AI, especially where you're in a chat and it's like the chat wants to show you a little map or it wants to show you a little product, or it wants to show you a little to do list. That's not a route anymore, right? That's just a component that has data and actions and stuff inside of it. You still are going to need a server on the backend to manage those actions and to get the data into that component. And so Remix for me is the Nintendo 64. Now there's this new world and our biggest bet is actually not on React. Our biggest bet is on the web APIs, fetch, request response, web crypto. There's so many APIs that we're starting to see run on more and more JavaScript servers, including Node. And so in a couple of years, to answer your question, I can't wait to see what both our team builds and what our community and the ecosystem develops around what we're building. The stuff that we're building right now for the next version of Remix is super composable. It's going to be consumable as like a framework, but the way that it's built isn't like you could use little parts of it. Even today already if you go to the React router docs to look at a file upload, how to do file uploads in React Router, you're going to bring in one of our Remix packages in the future version of Remix for multi part parsing, Astro Sites will be able to use this stuff, Solid start sites will be able to use this stuff, and just plain old web servers that need to support whatever you need. We'll be able to use everything in Remix and then we're going to package it up really nicely as like a framework with some docs that are like cohesive so it's not. You don't have to go to like 12 different readmes to figure out how to put things together. So yeah, that's, that's what I'm excited about. It's a big bet on the web platform anticipating more stuff like React server components, encapsulated widgets that can be easily like embedded anywhere into existing apps or Even generated by AI on the fly. We want to build a backend JavaScript infrastructure or architecture to support all that stuff in the future.
- [47:04]
Josh Goldberg
That's similar to the bet you've been making a lot of the time with Remix, right? Bet on the platform, bet on the web APIs, see where things go. That would be a fantastic way to close out this interview. If you'll permit me, Can I ask you one completely unrelated to Remix and React router question to actually close out though?
- [47:21]
Ryan Florence
Yep.
- [47:22]
Josh Goldberg
For the listeners. We did confirm this as a question ahead of time. How come there are so many JavaScript and React people in Utah? I'm legitimately interested in hearing your answer on this.
- [47:31]
Ryan Florence
I don't know. I don't know why we're just the loudest for some reason. Yeah, there are a lot of us. Me and Kent and John from A Head and Tanner from Tanstack. I'm probably, probably gonna have some people react rally. Jameson and Matt Zabriski ran react rally for a while actually. They're still doing that. I don't know if they're doing one this year, but yeah, there's a lot of us. But no, Utah is. I love Utah. Absolutely love Utah. Economy's awesome. The weather sometimes can be terrible. But that also gives us all the ski resorts. Like I'm within an hour of like, I don't even know what it is. Like 12 ski resorts. I only go to two or three of them. Just tons of stuff in the mountains. It's beautiful here. I love it. Super family oriented too. Everybody's. Everything is designed for families. When I lived in Washington, we'd like show up to a restaurant and they'd like give us a look like, oh crap, kids. But in Utah it's all fast casual and it's just 100% designed for people with kids. So yeah, we really love it here. The outdoor stuff, all the family stuff, it's fantastic.
- [48:31]
Josh Goldberg
That's really lovely. Well, cool. Ryan, thank you so much for coming on. I thought this was a phenomenally interesting set of topics. Remix, react router, the merge, the react router, and then the remix. And where you're all going with Shopify. Is there anything else you want to tell the listeners before we sign off?
- [48:47]
Ryan Florence
No. Buckle up. I don't think any of us really even know what the heck is going to happen with the web. This has got to be the most exciting time. The only precedent is the web itself with what's going on right now. So, yeah, I'm pretty excited to see where it goes.
- [49:00]
Josh Goldberg
Strong agree. For Software Engineering Daily, this has been Josh Goldberg. Thanks for watching everyone.