Kate: Hello, welcome to PodRocket. I'm Kate, the producer of PodRocket. With me hosting today is Kaelan. Hi, Kaelan. How's it going? Kaelan: Good. Great. Kate: Thanks for joining us as our host today. And then our guest today is Chance Strickland, software engineer at Remix Software. Hi, Chance. How's it going? Chance Strickland: Going great. Glad to be on. Kate: Thanks for joining us. Yeah, so just to get started, what is Remix in your own words? Chance Strickland: What is Remix? Remix, I would say, is a full stack framework for building better websites. It's built on top of JavaScript and React. So a lot of folks in the React ecosystem, especially, are going to naturally compare us to tools like Next.js, another popular server side framework for React. But I personally think a better comparison would be other full stack frameworks from other languages, like Laravel for PHP devs, Ruby on Rails, those sort of things that provide more of a true full stack experience to help you bootstrap really quickly. And our simple goal is just to help you build better websites, and that involves a lot of the key parts that I think traditionally have been missing from the React ecosystem. So that's it in a box. Kaelan: Yeah. I saw Remix made a lot of waves recently in the last year. Could you give me maybe, I don't know, a history of Remix or where it is now and where you think it will be? Chance Strickland: Sure, yeah. Kaelan: Next.js is pretty huge and seemingly has 30 releases now, and it must be daunting to go up against an established ecosystem like that. Chance Strickland: You know, that's funny because I don't think anything is an established ecosystem system in this industry. There's constant change and disruption. And to be clear, we're not trying to beat Next. We're not trying to beat other players in the JavaScript ecosystem. We're here to complement and provide experiences that folks might be missing out on in other frameworks. And that's totally fine. Some folks are going to use Next, and great, good for them. And some folks are going to find that other frameworks in other languages are going to fulfill their needs, then good, great for them. There's always trade offs in software, right? We obviously want to be used. We want people to use our software, and we think we're building really great software and we're going to empower folks to do the same with our software. So I don't think we're going to have any problem in regards to "competing" against players like Next in the React ecosystem. Chance Strickland: But also, I think it also misses the fact that Remix is built on top of React Router, and React Router has millions of users, millions of downloads. It was basically the first real good routing solution for React, and it's just been growing ever since. It's still growing today. Chance Strickland: So I think Remix is a very natural move for teams that are already using React Router, and that's who we're really reaching for. We're trying to reach out to teams that are using React Router. We're actually going to move a lot of the core features of Remix into the React Router, and we're already working on that. So I think it's going to be a really easy, nice transition for those users and those apps, and we're excited about what the future brings for React Router users, and for everyone else, for that matter. Kaelan: Yeah. React Router v6 I saw came out. Large amount of changes. It brings to mind the extremely rocky upgrade to v5 here at LogRocket. Chance Strickland: Sure. Kaelan: Took us quite a while, but I'm really excited for all the ideas that it brings, foundational rethinking of driving an app, at least in the React ecosystem. Chance Strickland: Yeah. So I actually have great news for you at LogRocket, then, because we just released a new compatibility package that helps the v5 users upgrade to v6. And the goal for that package is literally to wrap your app in this compatibility layer and upgrade your app basically one component at a time. It's meant to be completely back compatible, and it's meant to allow you to incrementally upgrade to v6 and v6 features as you go along. And when you're done, you just delete v5 with the compatibility layer. So we're hoping to make that process really simple in the future. Kaelan: That's good to hear. We probably will actually use that. Chance Strickland: Good. Kaelan: Do you have other similar things for people coming from Next.js and such? Because I feel like oftentimes these kinds of really cool tools are more often choices for people in new apps. So it's curious to me that you're focusing also on the upgrade path. Chance Strickland: Yeah, totally. And we don't have any automated tooling to help take your Next app and convert it to a Remix app. Maybe that's in the cards one day, but honestly, we're just very different. Our paradigm is very different. Some of our design patterns are very different, and we try to encourage that, right? The whole point of Remix is to encourage folks to build better websites, and I think our design patterns actually play a big part in that. When we start talking about some of the more technical pieces about how Remix works, we can try and dig into that a little bit, but fundamentally there's just a whole different paradigm for working in a Remix app than working in, say, a Next.js app. Chance Strickland: You can technically build a Next.js app that has a lot of the same features and components of a Remix app, but it's not quite the same process. It's not quite as frictionless, in my opinion. So they're just different tools with different paradigms. And so I don't know that we might have a simpler migration path at some point. I don't think it's terribly complex, because you can pull in all of your React components already. We're already going to support a lot of the popular data fetching libraries that you might be using, React query and those sort of things. You can still use those in a Remix app. So nothing should be theoretically broken. Chance Strickland: That being said, there's a lot of tools in the React ecosystem, and we're working constantly to improve support for various popular tools so that folks can have an easier time migrating. We do have some migration guides, by the way, on our doc site. So I would definitely encourage folks to check that out. Kaelan: Cool. Yeah. Speaking of the paradigm, I think the number one thing that stood out to me for Remix is the focus on the web standards, I feel like. Chance Strickland: Yeah. Kaelan: Curiously absent from the entire community. Web components came and went, it seems, for example, or all the new caching features that aren't fully quite adopted by the community but are actually adopted by browsers. So can you maybe speak to a little bit about the philosophy behind that and maybe why that is? Chance Strickland: Yeah, absolutely. And I think it's important to look at some history here, because React is several years old at this point. And I would say when we all started writing React code and before the app Angular, maybe, or different JavaScript frameworks, before we started doing a lot of the stuff that we're doing now on the client, we were filling in a lot of gaps from the browser, right? We were filling in a lot of gaps from the browser and from some of our backend, some of our run times. Chance Strickland: There's a lot to be desired in a lot of ways, and so we moved a lot of stuff to the client to shim some of those missing features that we really wanted. And unfortunately, we've held onto a lot of those patterns while HTML and the web has caught up and has actually gotten really good. Our backends have gotten really, really good. So there's a lot that we can do now that I don't think was quite as easy to do before, and that's one of the reasons we're pushing that focus on web standards is it's just easier to do that stuff now, and it's fundamentally going to be better for the user because it means you can ship less code to the client to allow them to do those sort of things. Chance Strickland: And honestly, I think of Remix as a teaching tool in some ways, because a lot of web developers got their start during that time period when web standards hadn't really caught up, so to speak. And we started using patterns that may have worked at the time. They may have worked well at the time, but honestly, some of those foundations were just missing from their education. And so in a lot of ways, I think Remix comes in to help folks learn some web standards along the way. It's kind of like an accidental teaching platform. People start using it and they're like, "Huh, I didn't know an HTTP response could do that. I didn't know a form could do." That's pretty cool. I think. Kaelan: Yeah. It's funny. The basic browser form [inaudible 00:09:13] was so popular [inaudible 00:09:15]. Nice to see it come back. Chance Strickland: Yeah. Kaelan: Yeah. It's interesting that you see it as a teaching platform. It reminds me a lot about, like you said, I think Rails is a good example of something that does a ton of magic, but maybe it's worth it to introduce new people. The trade off, I guess. Chance Strickland: And our two founder, I guess three co-founders now, Michael and Ryan, were both Rails devs back in the day. So their heart was set on Rails. And so a lot of folks, I think, see that connection. It was totally valid. I was a PHP guy myself, so I was working on the Laravel apps, but it's very similar. Some of these concepts that are, I think, normally opaque and just makes them a lot easier. And yes, there's some magic there, but it's nice magic, right? We like that kind of magic. Kaelan: Yeah. Also, another part that I liked was the focus on the stacks. It really does seem like you thought about everything. I think it reminds me of when server side rendering first came out and everyone was scrambling to there's this new technology and how to implement it from scratch. And there were so many boilerplate things coming up on GitHub that were thousands and thousands of lines long and held together with chewing gum and paper clips. Chance Strickland: Yeah. Kaelan: It's nice to see a full shebang that does it, does the job. Chance Strickland: Well, sure. We say we're a full stack framework and we want to be a full stack framework. So the stack is bigger than just the front end and the backend. There's tools between the two. There's tools for styling, for data handling, for database storage, for caching, you name it. You've got all these tools that otherwise you would have to piece together yourself. And if you have to piece them together yourself, what's the point of your framework? Right? Chance Strickland: So we wanted to make it easier to integrate those tools. I think stacks are an amazing tool for making that a lot simpler, and it allows people to create ... Our bootstrapping CLI allows people to create their own stacks. So if they don't like our particular flavor of choices, they create their own stack. They manage those dependencies, and you can actually bootstrap an app from anyone's stack anywhere on GitHub. So I'm really stoked about stacks. I think it's a great way to start a new app. Highly encourage folks to check it out. We've got three that we manage in-house, but a lot of folks in the community have already created their own. So lots of options out there for building your next Remix app. Kaelan: Do you have a favorite? Chance Strickland: I go to the Blues Stack myself. We name all of our stacks on genres of music. So we've got the Blues Stack, the Indie Stack, and the ... What's the third one? Off hand, I'm blanking on the third one. Kaelan: Grunge Stack. Chance Strickland: Grunge Stack. There you go. All of our Nirvana fans are going to love the Grunge Stack. I go with the Blues Stack. It's just got a lot of my favorite tools already baked in. Big fan of Prisma for our ORM. Kaelan: Me, too. Chance Strickland: I know the ORM thing is controversial for some reason, but I like ORMs. They help me ship apps faster, so no hate for Prisma here. Tailwind, really big fan of Tailwind, which was hard for me to admit, to be honest, because CSS is my love language. I love writing CSS, always have, and it took me a while to come around, but I get it. So I'm on Tailwind team now. So still love CSS, and occasionally I'll write it just for funsies, but I definitely am more productive with Tailwind. So it comes with all that stuff out of the box. Really love it. Postgres for the database. Big fan of Postgres. So yeah, just a great stack all around. Kaelan: Yeah. You seem to pick lots of tools that are known for their developer usability, I noticed. Chance Strickland: Well, I'm a developer, so I do like being able to use them. Kaelan: Who would’ve thought. Chance Strickland: Yeah. Kaelan: Another thing that I thought was extremely notable about Remix was the whole handling of the waterfall of loading spinners in the app. Chance Strickland: Yes. Kaelan: Can you talk maybe a little bit more about that? Chance Strickland: Sure. Well, I mean, so we have our concept of nested routes, and I think nested routes are, first of all, they're awesome. And we haven't really talked much about the technical stuff behind the scenes in Remix at this point, but essentially in all of your routes, so Remix is built around the idea of your routes, right? Your routes are your entry point. That's where your user hits a URL. It's going to hit the route associated with that URL, and that route contains a few different things. It's got your component code to render the route. It's also got your loader function, and it can have an action function. And those are the three main pieces to every route that cover both the front end and the back end with everything involved in that route. Right? Chance Strickland: So your loader, I'm sorry, your loader function is responsible for handling all your get requests on the server, right? You export a loader function, it's going to return an HTTP response based on whatever happens with that GET request. Right? You validate your data. You go fetch something from a database somewhere, and you return it so that response can contain whatever data you need to actually render the route. Right? Chance Strickland: And then you have your action function. Your action function is responsible for handling all of your post requests, handling data mutations. So user submits a form. That form data goes to the server. Right there in the same route that you render your form you can now handle all of the responsibilities of that form. So I think it's really great for co-locating that logic, right? React let us co-locate a lot of our logic, but traditionally on the client side. Now you get to also co-locate all your server code, which I think is really, really cool. Chance Strickland: And I think that's a really powerful tool when you talk about improving the whole waterfall effect. Where does the waterfall come from? What do you even mean by the waterfall? Well, if you go to a website, but first, if you open up your dev tools and take a look at the network tab, you refresh the page, you see all of your requests, right? All of the requests and the responses that come back from that server. And in React, we've done a lot. Reacts all about components, right? So let's say you have a subscribe form component. And traditionally in your subscribe form component, you are going to need to handle some of the data for that component, right? You submit a form, something has to happen, right? Chance Strickland: Traditionally in React apps, we've co-located that data in that form, which on the surface makes sense. Right? All of those requests are related to that component. So of course, you would put the request logic in that component. Unfortunately, if you've got 10 of those components spread throughout the page, you're going to make 10 separate requests, not concurrently, and you're going to get what we call a waterfall effect, right? The waterfall of requests. And that can really slow down your application, because your browser has to basically wait on one request to finish and then it starts the next request and it starts the next request. And you look at the chart and it literally looks like a waterfall, right? Chance Strickland: Well, in Remix, we have the patterns to encourage you to move all of that logic into your routes, into the server side handlers so that all of that logic is sent back from your loader or your action, or all that data rather, and then you can handle it directly in your components. You can still have your nice form component that handles your subscribe form. But you do all that in server at the route level. And you still get the nicety of co-location, but you also have a much easier time preventing those subsequent requests that are going to slow down the website for your users. So I think that's a really great feature of Remix Routes. Chance Strickland: And I mentioned nested routing, too. So if you've got a parent route that loads some data, that data will also be available to your child routes. So you don't have to go and make separate requests for that. So all of these patterns, I think, really encourage practices that will ultimately reduce the "waterfall effect" when it comes to data fetching. Kaelan: Very nice. I haven't seen something like that in other frameworks, or at least not this fleshed out. Chance Strickland: Well, you can technically do that in other frameworks, but I think design patterns are really important, and design patterns are what encourage us as developers to make the decisions that lead to those sort of things. Right? And for a long time, I think frameworks have been so focused on developer experience that we've let user experience take a backseat, which is understandable. We want to have a good time as developers. I want my code to be easy. I want my error messages to make sense. I want an easier time doing my job. So I'm not blaming people for wanting good DX, but we can't let the user experience suffer as a result of that. And so I think the design patterns in Remix are very powerful in encouraging folks to make the right decisions for their users. Kaelan: Yeah. I think also part of it is convincing people that it won't take too much time to do it the right way. Chance Strickland: Absolutely. Kaelan: Tools like Remix, if they can convince the engineers and PMs that it won't take longer, I think, will get very far. Chance Strickland: Reduce your project management waterfall as well. Right? Kaelan: Both waterfalls. Yes. Chance Strickland: Yeah. Your Gantt chart. I used to be a project manager, so I immediately saw a Gantt chart in my brain when you said that. Kaelan: I'm sorry. Chance Strickland: Yeah, me, too. Kaelan: Well, everything seems to go back to the routes. Chance Strickland: Sure. Kaelan: I definitely have to check this out. I'm getting excited even talking about it. Chance Strickland: It's funny, because every time I talk about Remix and I talk about routing, I'm convincing myself more and more, too, because we're a new framework. I took some convincing at first. I'm a skeptic with everything. I was a long time Next.js user. I don't have any hate towards Next these days myself, but yeah, these are new patterns and the more I talk about it, the more stoked I get about using it myself. I've got a couple side projects in works, and I'm excited to actually build them with Remix. Because you work on a framework and you know a certain amount, but you don't really find out what it's really like until you build an app with the framework. So it's nice to be able to get to do a little bit of both. Kaelan: Yeah. I guess I would put Next and maybe a couple other frameworks in almost like a new era of a new wave, I guess, where React was the previous one. Chance Strickland: Well, that's why I started the conversation by basically suggesting it's not a great comparison, right? They're just different tools with different paradigms. And yeah, it's a natural comparison. I know why people want to reach for it. But I just think there's just so many different things that we offer that I feel like separate it categorically from tools like Next. Kaelan: Right. I meant more like a generation divide, more like where I often say this in other podcast episodes, but we have so many people come onto the podcast and they talk about what they work on. And one thing that always comes to mind is how web development seems to go in stages of everything should all be magic. Chance Strickland: Sure. Kaelan: One framework to rule them all. Chance Strickland: A circle, some might say. We just make a loop. And before- Kaelan: Then we go back to- Chance Strickland: Yeah, I think it's more like a spring, right? We do slowly make progress, but we do go in these spring-like circular shapes and movements sometime where we end up coming back to where we started. But it's incrementally better that time, I hope. I think every point on the spring is useful. Right? We learn new lessons every time we go through that movement. But yeah, I hope we're at the next real breaking point in that spring and we really launched some of the thought leading, so to speak, forward. I'm really hopeful. Kaelan: Yeah. I think you can compare it to the previous generation where you had to do everything all yourself. Chance Strickland: If I never have to [inaudible 00:21:37] again, I will be stoked. Kaelan: Yes. So I did [inaudible 00:21:42], so I'm ready to burn it in a fire, I think. Chance Strickland: Good. Remix has its own compiler, too. I don't think I mentioned that, but that's another key part of Remix. There's- Kaelan: Sold. Chance Strickland: Yeah. Kaelan: That's all you have to say on the website. [crosstalk 00:22:01]. Chance Strickland: You never have to write compiler code ever again. Be happier. Kaelan: I don't think we talked about the future too much, but maybe you want ... Anything you can share or secrets you're willing to share for the first time? Chance Strickland: Yeah, I don't have any if I tell you I have to kill you kind of things. We're open source. So we do a lot of our work in public. We have the internal discussions obviously, and we have thoughts and plans and debates, but a lot of our stuff is out there. If you take a look at the discussions tab, you'll see some discussions that we've started, that I've started on various features that we're hoping to support. Chance Strickland: One of the features that I've been working on recently is a CSS module support. So it will be easier for users who are using CSS modules to migrate their applications. Because we write our own compiler, we have to basically write a lot of the support for those external tools ourselves, and we want to be very thoughtful about how we do that. So we don't want to introduce something that creates a bad place or a bad way to back out of bad decisions, essentially. We want to make sure that the right decisions and executed the right way, and there's a lot of complexity to stuff like that. So we're taking our time with it, but we are really hopeful and we're pushing forward in a lot of new features. So CSS modules is one of my favorites that are coming down the line. Chance Strickland: Right now, we're really focused on stability. So our immediate plans are really built around just making Remix really solid, bulletproof framework. And by the time we're ready for a v2 and we're ready to roll out a bunch of really cool new features, we want to be really confident that v1 is as rock solid as it possibly can be. So I'd say that's our immediate focus. We do have some v2 plans and thoughts and ideas, but they're kind of baking right now. So I'll just leave some of that to the suspense of your imagination. Kaelan: Sounds good. And I hear you have a conference, too. Chance Strickland: We do, yeah. It's coming up in a few weeks. Well, a few weeks. But if you go to Remix.run/conf, as I'm doing right now, you'll see that it starts on May 24th to the 25th. We do also have workshops on the 23rd that will be led by Kent and Ryan and possibly another workshop that we'll squeeze in there. But yeah, we're really excited about it. It's in Salt Lake City. I lost. I tried to push towards San Diego but couldn't make it happen. So it'll be in Salt Lake, which is beautiful. Really excited about it. Hope to see you there. Got a lot of great speakers as well, so definitely come to that. Kate: Awesome. Yeah. Is there anything else you'd like to plug or point our listeners to? I saw your Discord channel just hit I think it was 10K. Chance Strickland: Oh, man. That's too many. I'm kidding. Kate: That's a lot. Chance Strickland: Come join Discord. There's a lot of great conversation there. I can't keep up with Discord personally, but we have a lot of other team members who do and they're all really great. And it's really nice to be able to get feedback from other users, and Discord is a great community for that. So definitely come join our Discord. Remix.run is our website. All the stuff that you need to join Discord is right on there. I'd be remiss not to plug, I guess, myself, because I've talked more about my company than myself. So I'm Chance. I'm a developer. You can follow me on Twitter, chancethedev. I don't know. I post a little bit about tech and a lot about nonsense, but I try to have fun. And yeah, I don't know. Come use Remix. It's a lot of fun. Kate: Awesome. Well, Chance, thank you so much for joining us, and we will see you around. Chance Strickland: Absolutely. Kaelan: Thanks for coming on. Chance Strickland: Thanks for having me. Kate: Thanks for listening to PodRocket. You can find us at PodRocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.