Ben:
Hello. And welcome to PodRocket. Today, I'm here with Michael Jackson, who is the co-founder and CEO of Remix. How are you, Michael?

Michael Jackson:
Hey, I'm doing awesome, Ben. Thanks for having me on the podcast.

Ben:
I'm glad you could join and today I think we're going to mostly talk about Remix, which I'm guessing it's a topic you know a lot about given you are the founder of Remix. So maybe for folks who are not as familiar, could you give us a quick overview, what is Remix?

Michael Jackson:
So Remix is a web framework that we're building. It's built on top of React and React Router, currently. That's some technology that we've been working on for the last eight years. It feels weird to say eight years, but React, I guess, is pretty old at this point. And so we're building it on top of React Router. And the way that we like to say it is, we're building better websites. We're building websites that are based on web fundamentals and standards and progressive enhancement.

Ben:
Got it. And so built on top of React and React Router, and what does Remix give you that you don't get out of the box with React and React Router?

Michael Jackson:
So the way that I've been talking about Remix is as like a compiler for React Router. My co-founder and I, Ryan Florence, have been working on React Router for a long time now. And we've always had this vision for what you could do with React Router, and specifically with nested routing and the kinds of optimizations that you could make to a website if you broke down the page essentially into these chunks. So that's what nested routing is at its heart, is you take a webpage, consider the GitHub UI, which is hopefully a UI that a lot of listeners are familiar with. You've got this global nav, which you have your user icon up there, you have maybe some nav that's specific to the repo that you're looking at or a repo level nav, and then you might have a file browser nav. Or if you're in the settings pain, you're going to have the settings nav over on the left. So you've got these boxes that are nested inside boxes on the page, and in React Router those are what we would call nested routes.
And what happens is when you break up the page into nested routes and treat them individually, you can perform lots of really interesting optimizations and enable workflows even that are difficult when you don't have that concept. So that's the key thing that React Router adds to React. And then the thing that Remix really adds is a server run time that allows you to deploy anywhere and a compiler for Remix projects that supports all kinds of different things, like TypeScript and JSX and all that kind of stuff.

Ben:
So would it be accurate to say that Remix is a alternative to using something like Next or Gatsby? Is that the right way to think about it?

Michael Jackson:
Yeah, absolutely. Remix is a website builder. And obviously those two projects that you just named have been around for a while now. And when we were building React Router, our hope was always that somebody would take this idea of nested routes and would really run with it and build a web framework with progressive enhancement in mind, with all of the webby things. We we've been developing web for a long time now and nobody really did that, and at least not to our degree of satisfaction. So we decided to take it on ourselves and we've been having a ton of fun doing it. We've got a great team that's working with us now. We actually raised some money last year to work on it. And we've got people just from a lot of different backgrounds that are really interested in working on Remix and helping us out with it. But yeah, it's definitely an alternative to Next or Gatsby. We also view it as a budding alternative to projects that are a lot more mature, like Laravel or Rails, if you're from either of those communities.

Ben:
So in the context of Next, because I may be wrong about this, but I think Next is the most popular framework website building tool nowadays. What are the pros and cons to using Remix and how are you thinking about positioning against Next?

Michael Jackson:
So Next is quite popular. It's actually not as popular as React Router. You might be surprised to find that out. I think a lot of people, they look at React Router and they look at it as more of a library instead of a framework for building websites. But it absolutely is. It's the backbone to many, many production apps. Netflix.com, twitter.com, lots of products at Google, at Airbnb, at Dropbox have been built with React Router. And it's something that... I mentioned to you before we started recording, Ryan and I used to have a training business, React Training. Still do, actually. You can go and get React Training for your teams, reacttraining.com. But anyway, we spent a number of years, like five or six years, with this training business traveling around the world. We've been to Boston, a number of times, Chicago, but we've also been to the U.K., we've been to Australia, holding these training workshops and meeting people who are using React Router in real life to build their real apps, to build their dot coms.
And a lot of that experience has informed the way that we've built React Router itself. The API design is not just designed for like, "We think this is a good API for developers," but we actually think it's a really, really great API for organizations for large teams. There comes a point in API design where , if the project gets big enough, you stop thinking about... Or you don't stop really thinking about anything, but you start thinking about what does it take to build a large app? Are we code splitting? We've probably got different teams that are focused on different features of the app. How can we make it easy for those different teams to do their own jobs and still work together? So anyway, a lot of this stuff came into our radar and our thinking when we had this training business. And when we went back and we saw the way that people were building apps with React Router, we thought, "We could really take this a lot further and we could really help people build amazing sites if we just added a little bit to this framework that we've already built."

Ben:
Enjoying the podcast? Consider hitting that follow button for more great episodes.
Got it. So basically wanting to give developers more out of the box, more on top of React, reality, just build apps without making as many decisions. Is that the right way to think about it?

Michael Jackson:
Yeah. I think that's a great way to think about it. We had all these people that were building stuff with React Router, and then they were like, "Well, how do I do styling"? That's a huge, legit question. How are you going to style your app? Well, there's lots of different ways to style your app, obviously. "Well, how am I going to manage data loading? How am I going to manage data mutations? How am I going to deploy the thing. There were so many questions that React Router, as a framework, didn't really answer because we were trying to be as flexible as possible in all those different situations. But then I think we realized we can actually provide a ton of value for people in answering these questions, but what we have to do is do it in a way that they can stitch them together themselves.
So one example of that is our current backend infrastructure in Remix. We are not a hosting company, so we're not optimizing for any specific hosting backend. Remix works great on Netlify works great on Vercel, works great on any Node host that you might want to deploy to. Also works really, really well in non-N,ode environments. So you want to deploy to Dino or Cloudflare Workers, we'll run there too. We've already got a Remix experimental build that's running on Bun, which I think was just stable a couple of weeks ago. So that's an example I think of we want to make a framework that doesn't really force too many opinions on you. The things that we really, really care about are optimizing the user experience, providing an accessible experience and not sacrificing on performance and using progressive enhancement of web standards, which it was a huge reason for us creating Remix, because we thought we could do it a lot better than existing solutions were doing that.

Ben:
And so maybe talk to me a bit more about some of the opinions that you've taken with Remix in terms of what you mentioned, like styling and data loading and I guess state management. Have you brought in certain third-party tools or built some of those things yourselves? Help me understand that a bit more.

Michael Jackson:
Yeah, absolutely. So let's just talk about state management, for example. Let's talk about managing the data that's on the page, because that's a huge problem for a lot of web apps. And I think there's actually a lot that your framework can do for you to make it really, really nice. So when it comes to data management and state management, there's two sides of the coin. There's data reads and data writes. One is the initial loading of the data and then the other one, they call mutations sometimes. So how do you get the data on the page? Well, that's actually a really interesting question. There's been a lot of innovation in that space, especially React itself is experimenting with is streaming and things like suspense.
And so it comes back to this idea of nested routing. So let's say you were building an app, like GitHub, where you've got a bunch of nested routes. So in Remix, you actually have a separate data loader for each one of those routes or each section of the page, rather. So let's say that you're, again, just to stick with the example, you're building GitHub and let's say you're navigating around on the settings page and you click one of those little links to go to a different part of the settings page. In a single-page app, you're not going to refresh the entire page. You only want to fetch the portion of the page that you don't have yet, which is the next view in that little nested section of the page.
So the way that Remix has separated out the sections of the page, we know that you only actually need to call the loader for that one small section of the page that you need to load. You don't need to reload the global nav. You don't need to reload your user avatar, for example, you already have all of that information. You only need to load one small section of the page. So that's the kind of thing that Remix does for you automatically. At each route or for each little view that you have, you declare its data dependencies in this thing called your loader, which stands for data loader, but we'll automatically call your loader as needed. One interesting thing about these loaders is we will actually recall them when a mutation happens.
So that's actually something that is built right into the framework. So lots of people will typically bring in something like React query or whatever, or Apollo or whatever. They'll have their data fetching. They're doing it in a useEffect. In Remix, we use forms for data mutations. So by the way, your Remix apps usually will work without any JavaScript on the page at all. We just use JavaScript to enhance the experience. But we know that when you are building a single-page app and you're submitting a form, or let's say you're doing a fetch call, that's fully supported as well. We actually know when those mutations are occurring. So let's say you've got a form on the page, you're going to save some data. A mutation essentially means that the state on the server has changed.
And so we will actually go and recall the loaders by default. You can opt out, if you want to make some optimization. But by default, when a mutation occurs, we'll actually go and recall the loaders on the page. So what does that mean? Let's say, again, you're in your GitHub UI and you're updating your user profile settings. You're going in there, you're updating maybe your name, your username, or your user avatar. Obviously, that avatar is present in the global nav and yet you're mutating it in this settings view that is deeply nested in the page. That's the kind of thing that Remix will automatically handle for you when you go and you update your user avatar, even though it's in the global nav, since that data is part of your global nav data and associated with the top level root level route, we will actually go and recall that loader for you. So as soon as you save that image, perform that mutation, we will refresh any stale data that's on the page.
So that's just a really broad, general example of the kinds of things that you would have to think about if you're a web developer. You're developing an app, you're making mutations all the time you need to think about "How do I refresh the stale data that is already on the page? That's a huge problem. And that's something that we've built right into the framework for you. So both the loading of the data on a granular per route level, but then also the reloading of the data when that data is stale and the incorporation of mutations as a first class citizen in the Remix API.

Emily:
Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts, so we can continue to bring you conversations with great devs, like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show.

Ben:
I'd to better understand the concept of nested routes. I know that's something that is key to Remix. So can you explain nested routes a bit more and some of the magic Remix does around those?

Michael Jackson:
Yeah, yeah. 100%. So in addition to the data loading that we do around nested routes, so again, nested routes, the way I think about it is it's a way to split up a webpage into more granular pieces, so that what are the layouts and what are the views on this page? And so you can associate data loading with nested routes and also data mutations with nested routes, as I already mentioned in the previous example. But we even take that a couple levels further. So we will actually do code splitting for you based on your nested routes. So let's say if you have three or four routes on the page, like in the GitHub example that I've been using, each of those components that represent those routes, we will load each of them from their own bundle. So when you navigate using that sub nav, we'll actually load just the code necessary to render the next view in that nested view that you're navigating to. So we'll do code splitting for you automatically based on nested routes. We'll also do styling for you based on nested routes. So this is actually something that's really cool.
And it's something that I don't think we've actually really talked a whole lot about, but Remix actually does some really cool things for you when it comes to styling. So just like you associate data loading on a route level, you associate styling on a route level. And it goes beyond styling. It goes to any link that you want to associate with a route, but let's just talk about REL=StyleSheet for now. So we'll automatically split your styling for you based on the route that you use it in. And then when that route appears on the page, we'll load that style sheet. And when that route goes away, because you navigate to a different page, we'll actually remove that style sheet from the page.
So the traditional state of the art when it comes to styling is take all of your styles, bundle them up into one style sheet, throw that on the page. Maybe you obfuscate the class names or whatever, so that you don't have clashing, or use something like CSS and JS, which will automatically obfuscate them for you. I'm not going to say that's not a problem in Remix, because those techniques are still valid, obviously, according to whatever you're building, but it is much less of a problem when you don't have all of the CSS on the page all the time. You know what I'm saying? You have the portions of the CSS that are necessary to render the page are on the page. The portions of the CSS that are not necessary are not there. Just like the JavaScript code. We load the JavaScript code that is necessary for the current page. We don't load all the JavaScript code that is necessary for all the other pages until those pages are needed. So that's another way that the nested routes are useful, both in the data loading and the styling.
I also mentioned links. So when I'm talking about links, I'm talking about the link tag, the one that appears in the head of the document, not the anchor tag. So the links are actually, you can use them for pre-loading, you can use them for pre-fetching and we can associate those on a per route basis as well. So as soon as we know that one of your routes is actually going to pop into the view, we can go and we can pre-fetch everything that you have declared in your links method that you need for that route before making the transition to that route. So you can think about it as a suspense transition that is built into Remix itself.
And the end effect is it's really nice that the framework does a lot of this for you, because a lot of this stuff that you were managing by yourself in useEffect. You were managing your data mutations, you might have been managing dynamically loading code or dynamically loading styling, or something like that. Or loading from a cache. A lot of those are concerns. Those are concerns that basically every web app has and we're incorporating them into Remix, into the framework itself. And just trying to provide the right hooks for the happy path, but then also give you opportunities to opt out of our optimizations when you don't need them, like a shouldComponentUpdate. We've got those hooks all over Remix to let you opt out of stuff.

Ben:
So I want to understand more about Remix organization and the business. So correct me if I'm wrong, but is Remix a company or an open-source project? What's the organization and the goals long term?

Michael Jackson:
Yeah. So both. Remix is an open-source project. You can find us on GitHub. We're under the remix-run org. So it's an open-source project run totally out in the open in GitHub. It's also a company that we've formed around it. So, like I said, last year we went out and we raised some money and we went and hired some folks to help us develop Remix. And so the ethos of the company is really open source. We've been doing open source now for eight years. We believe very strongly that open source is the future of software. If you're building something in software and it's not open source, somebody is going to build an open-source alternative, which doesn't necessarily mean though that everything is always free.
The source code is definitely free, but I think that the commercial open-source model is that you can sell services to people who are part of the community. So the code being open source doesn't mean that the company will never make money. We've actually seen quite the opposite. In the last decade, we've seen numerous commercial open-source companies that have built very successful business models based on... even though a lot of their core open-source software has been free to use.

Ben:
And what are you thinking in terms of business model? You mentioned earlier, not being a hosting provider necessarily. Is that in the card down the road or are you looking at other options for monetization?

Michael Jackson:
So that's a great question. I think one of the strengths of Remix right now is that we are not coupled to a particular hosting provider. I think if a framework is coupled to a hosting provider, there's incentives there for that framework to work really, really well on that particular hosting provider and neglect others, which limits the options that you have as a user of that framework. But there are a lot more things that we can sell besides just hosting. There's analytics, like what you all are doing at LogRocket. There are asset hosting, like what people at Cloudinary are doing. There's database management. We actually just held a conference last month in Salt Lake, Remix Conf.
And it was so awesome. We had hundreds of people there. We had a bunch of different sponsors and they were coming from all over the landscape. We had very large infrastructure providers there. We had application hosting. We had monitoring and logging. We had database application management. We even had WorkOS was there a lot of different companies were there. There was Tooling. NX was there. Vercel and Netlify obviously were there. So it was cool to see just how many vendors there are in this space. And there's plenty of room for us to come along and participate in that ecosystem and even provide a marketplace for Remix users and provide integrations with all of the various services that are out there that we can use to provide value for Remix users.
So as far as our business model specifically, that's where we are focused, is providing seamless integrations with any of these services that you might want to use, whether it's hosting your images, or somebody to host your data, or somebody to do the logging for you. We integrate with everybody. And I think that provides a tremendous amount of value for our customers, for the industry and for the company.

Ben:
And going a bit broader, tell me more about the vision for the next year, and then also long, long term. What's exciting to you that's on the product roadmap and more on the business roadmap overall?

Michael Jackson:
Yeah, absolutely. I'd love to talk about it. So I think immediately on the product roadmap, what we're really excited about is our streaming support that we've got for both for React 18 and then also for other frameworks that we're working on. But what happened with React 18 was React 18 shipped with some really, really nice primitives. They've got pipeTo, ReadableStream. I forget the method names, but basically they have support for streaming on the server. They also shipped support for suspense. They didn't do that in React 18. That's been out for a while. But they're iterating on their streaming story with these low-level primitives. But what it really requires is a framework to come along and stitch it together and make the cohesive story for the end user. And that's what we've been working on with Remix, both in React Router and in Remix itself.
So one of the really cool things is that we're actually just bringing this to React Router. So you don't even have to use Remix if you don't want to. If you've already got your webpack thing and you're happy with how you're running your servers and stuff, that's fine. Bring your own compiler, bring your React Router app. We're actually going to give you all of the loaders and actions, the data abstractions that I was talking about earlier for loading and mutations, we're bringing those directly into React Router. So React Router 6.4 is going to incorporate all of those. There's some really cool stuff in there, lie we bring error boundaries. So in addition to a loader and an action, you can associate an error boundary with your routes, which gives you really fine grained control over error handling on a per route basis. We're bringing that also to server rendering. So it's really, really cool stuff.
And again,, that's just in React Router. Of course, these are things that we learned building Remix that we're bringing into React Router. So we're shipping that for all React Router users in a dot release, a minor release. So you don't even have to upgrade your app with a bunch of breaking changes. As long as you're on Reactor Router 6, which we've had out there stable for a long time now, you're going to be able to take advantage of all these features. So I'm really excited about that. Obviously, we're going to be building Remix on top of React Router 6.4, reworking Remix to take advantage of the actual abstractions that we have in React Router. And then doing a lot of streaming support as well in Remix.
So that's on the immediate roadmap, stuff that we're immediately excited about. More long term for the remainder of this year, we're actually going to be taking a closer look at our compiler. I think it's become a bottleneck for us at this point. It's worked great up until this point, but I think we could probably be doing some things better there, particularly in opening it up for other people to do the types of things that they're trying to do. The whole ethos of Remix is we don't want to force you too much into any particular technology. So I think there's some work for us to do in opening up our compiler, making it easier for people to do things, like hot module reloading, using various CSS strategies.
We're actually going to be shipping a plugin for webpack, which I'm pretty excited about, that will allow you to compile your Remix app with webpack. That's part of opening up our compiler as well. We're not super opinionated there. We don't care how the thing gets built. We just care that it's a good experience obviously. The thing that we really really care about is the framework itself. I like to say we really care about the Network tab. We really care that you don't bork the performance of your app. So no reason for us to enforce our opinions in areas that we're not really trying to innovate in. So we have some work to do in the compiler.
We also have some work to do I think with just our various integration partners. We're going to keep expanding our network. We've got a pretty good network thus far. We've integrated with numerous application hosts, numerous database hosts. And even things like Century, I think, is going to be launching an integration with Remix very soon. So lots of different integrations with different people in the industry, so are going to be expanding our network. And I think that's the big play for Remix, if you're talking about long, long term. Creating the best-in-class web framework is really just opening the door to building a great community around this framework and then inviting basically everybody to the party.
Again, if you're a database host or an application host or a monitoring provider or whatever you're doing doing, there are numerous different companies selling to web apps, both in the backend and on the frontend, selling CSS and selling all kinds of different services. That's I think where we can provide integrations and then we can monetize by just selling best-in-class integrations with all of these different providers.

Ben:
Well, Michael, it's been great having you on the podcast, and I've really enjoyed learning about Remix. For anyone out there who's interested in learning more, the website is remix.run. Is that the best place you'd recommend for people who want to get started or any other resources you would point people towards?

Michael Jackson:
Yeah, absolutely. Remix.run, reactrouter.com is another domain that we run specifically for React Router. But remix.run is the best place. You can follow us on Twitter at remix_run. You can follow our activity on GitHub at remix-run. And those are all great places to keep up on what we're doing. Go to remix.run and sign up for our newsletter if you want to keep up to date on the latest and what we're working on.

Ben:
Awesome. Well, thanks so much, Michael.

Michael Jackson:
Thank you, Ben. It's been a pleasure.

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.