Remix with Kent C. Dodds

Episode Description

Kent C. Dodds discusses his role at Remix, how the framework bridges the network chasm, and why it targets React Router's massive user base.

Episode Summary

Kent C. Dodds joins the show fresh from a serious car accident to talk about his new role as Director of Developer Experience at Remix. He explains how he fell in love with the framework after rebuilding his personal site, which led him to join the company full-time. The conversation covers what makes Remix distinct: its focus on bridging the gap between client and server rather than sitting on one side, its embrace of web platform APIs over proprietary abstractions, and its use of progressive enhancement rooted in a web 1.0 mental model. Kent contrasts Remix's approach with other frameworks, discussing why the team is bearish on Jamstack, cautious about React Server Components in their current form, and skeptical of techniques like partial hydration until they prove themselves in real user experiences. He explains why Remix positions itself as "center stack" rather than full stack, with plans to gradually expand into both client and server territory. The discussion also touches on deployment strategies, including Kent's experience running his site on Fly with globally distributed Postgres and Redis, as well as Remix's compatibility with edge platforms like Cloudflare Workers. The episode closes with Remix's long-term vision: migrating the millions of existing React Router users and ultimately making the web better by default.

Chapters

00:00:00 - Kent's Car Accident and Recovery

The episode opens with a striking personal story as Kent C. Dodds recounts surviving a devastating car crash at a four-way stop, where a truck ran through the stop sign at high speed and struck his driver's side door. He shares the surreal experience of being told he should have died, along with the injuries he sustained including a broken collarbone and two front teeth.

The hosts reflect on the emotional impact of hearing about the accident from someone whose work they follow closely. Kent's remarkably positive attitude shines through as he notes that anything short of death feels like a blessing, and he expresses gratitude for having engaging work to keep his mind occupied during recovery. A brief tangent about American versus British driving conventions and roundabouts adds some levity.

00:03:16 - Kent's Role at Remix and Developer Experience

Kent describes his day-to-day responsibilities as Director of Developer Experience at Remix. Before joining, he was a full-time educator known for Epic React and Testing JavaScript, but after rebuilding his website in Remix, he became so passionate about the framework that he wanted to teach nothing else. He coordinated with co-founders Michael Jackson and Ryan Florence and officially joined the team.

His work spans organizing Remix Conf in Salt Lake City, supporting local meetups around the world, maintaining documentation, and planning a comprehensive free educational program comparable to Epic React. The team's primary objective is driving adoption, with Kent emphasizing that people tend to be impressed once they actually try the framework. All educational materials will be free since the company's current focus is growth rather than monetization.

00:06:46 - What Remix Is and How It Works

Kent offers his personal definition of Remix as a framework that lets developers build excellent user experiences without being ashamed of the code required. He walks through the technical fundamentals: server rendering by default, HTTP caching as a substitute for static site generation, and the ability to shift between caching strategies without re-architecting an application.

The conversation touches on progressive enhancement as a core philosophy, where applications work at a web 1.0 baseline and JavaScript layers improvement on top. Kent also addresses React Server Components, explaining that Remix evaluated them internally and found them lacking for production-quality user experiences, though the framework could adopt them with minimal breaking changes if they mature.

00:10:37 - Evaluating New Technologies Through User Experience

Kent articulates Remix's philosophy of judging technical innovations by building real applications rather than relying on theoretical benchmarks. He discusses frameworks like Qwik and concepts like partial hydration, acknowledging their technical merit while pointing out that holistic user experience sometimes tells a different story than isolated performance metrics.

The hosts share their own experience migrating from Gatsby to Next.js for an e-commerce site, encountering cascading problems with build times, ISR, and API rate limits. This leads into a broader discussion about how the Jamstack category is fragmenting, with Remix firmly positioning itself outside that label. Kent argues that ISR was a band-aid for a self-inflicted wound and that server-side rendering with HTTP caching avoids the problem entirely.

00:16:30 - The Web Platform and the Network Bridge

Kent explains what he sees as Remix's most defining characteristic: rather than being on one side of the network and reaching across with grappling hooks, Remix builds a solid bridge between client and server. This means state management simplifies dramatically because the database effectively becomes the global store, eliminating the need for tools like Redux.

He contrasts this with the traditional client-side approach where mutations require manual state synchronization, explaining how Remix adopts the web 1.0 model of form submissions and full-page data refreshes, then optimizes from that correct default. The discussion highlights how Remix uses web platform APIs like fetch request/response objects and link prefetch tags rather than creating proprietary abstractions, which keeps the framework lean and leverages what browsers already do well.

00:20:59 - Full Stack, Center Stack, and Migration Strategy

The hosts raise the question of whether Remix qualifies as a full-stack framework. Kent introduces the "center stack" concept, explaining that Remix's strength is managing the network layer, with plans to gradually expand into both client-side components and server-side tooling like ORMs. He notes that while Prisma integration exists, baking in a specific ORM would limit Remix's appeal to teams migrating existing applications.

Kent reveals that React Router powers roughly seven out of ten React sites, making it an enormous migration target. He emphasizes that Remix is essentially an upgrade path for React Router users and contrasts this strategy with competing for Next.js users. The conversation also covers how React Query and similar tools become unnecessary in a Remix context, though Kent takes a diplomatic approach, letting developers discover this on their own.

00:31:12 - Deployment, Edge Computing, and Runtime Flexibility

Anthony asks about deployment strategies, prompting Kent to share the detailed architecture behind his personal site. He explains choosing Fly over Cloudflare Workers due to needing runtime tools like esbuild and ffmpeg, and describes his globally distributed setup with Postgres read replicas and Redis caching that delivers sub-250-millisecond response times worldwide.

Kent explains that Remix was designed with edge computing in mind from the start, which is why it adopted web platform APIs for requests and responses. This design choice also opens the door to running Remix in service workers for fully offline applications and supports experimental Deno compatibility. The flexibility to deploy anywhere JavaScript runs is presented as a key architectural advantage.

00:35:02 - Framework Agnosticism and Supporting Other Libraries

The conversation turns to whether Remix could work without React. Kent explains that approximately 80% of Remix is already framework-agnostic, with the remaining 20% being the router. The team plans to create a framework-agnostic router with adapters, starting with Preact support, which would then make it straightforward for the community to build adapters for Vue, Svelte, or Angular.

Christopher notes that the Remix homepage downplays its React dependency, and Kent clarifies that the team prefers being called a web framework rather than a React framework. While other framework support isn't a high priority given React's dominance, the architecture is being designed to make it possible with relatively minimal adapter code.

00:39:10 - Remix's Vision and Closing Thoughts

Kent shares the ultimate goal for Remix: making the web better than it was before. He recounts how Ryan and Michael are personally motivated by encountering terrible websites built with React Router and wanting to ensure their software leads to better outcomes by default. The vision is to upgrade the massive React Router user base to Remix and demonstrate that great developer and user experiences can coexist.

The episode wraps with Kent directing listeners to remix.run and kentcdodds.com, highlighting the two available tutorials ranging from a quick conceptual overview to an in-depth project build. He encourages attendance at Remix Conf in Salt Lake City and participation in the Discord community, emphasizing the exciting educational content planned for the near future.

Transcript

00:00:00 - Anthony Campolo

[unclear], you're like, wait, the universe is just random and bad things can happen to good people. Kent, welcome to the show.

00:00:16 - Kent C. Dodds

Hey, thank you so much. I'm super happy to be here. Thank you for inviting me.

00:00:19 - Anthony Campolo

It's going to be really great. We're going to talk about Remix. We're going to talk a little bit about what you do on the team and some of the things you work on as well. Many of our listeners will already be familiar with some of your work. You're a very prominent React educator, React developer, and general Twitter online personality. We usually don't do topical things on this show, but I think it's only been about a month now since you were in an almost life-ending car crash. You were T-boned, correct?

00:00:46 - Kent C. Dodds

The short story is I was at a four-way stop, and I was going through the stop sign. A big Dodge Ram 2500, a big truck, blew the stop sign at 80 miles an hour and hit my door, right on my door. I still can't believe that I didn't die from that. Everybody on the scene said I should have died, which hits me every couple of days. I'm like, oh my gosh, I almost found out what happens. It's pretty crazy. So happy to be alive.

00:01:13 - Anthony Campolo

Yeah. I have a vivid memory of exactly where I was when I read the news because, as I say, a lot of people follow your work. Seeing someone that you like, kind of feel like you know a little bit through proxy, through their work, having something like that happen, it's one of those moments you're like, wait, the universe is just random and bad things can happen to good people. Dang. But you had such a good attitude about it. You're tweeting from the hospital and letting people know you were okay. I thought that was awesome. You had such a positive disposition to this really terrible thing that had happened.

00:01:47 - Kent C. Dodds

It's hard to complain when you should have died. Anything short of death is a blessing. I guess I did break my collarbone. That has not been awesome, but I'm recovering fast. Faster than expected, but slower than I'd like. I broke my two front teeth, so my teeth are fake now. I hurt my foot quite a bit, but other than that, I'm doing great. I'm happy to have things to engage me so that I can not think about it all that much.

00:02:11 - Anthony Campolo

That's good. Yeah, I had messaged you right after it happened saying, hey, if you need to reschedule the podcast, that's fine. You're like, nah, let's do it. So that's awesome.

00:02:19 - Kent C. Dodds

I need this. Yeah, I'm...

00:02:21 - Christopher Burns

I'm from the UK, and obviously we drive on the other side of the road. The first time I went to America, the weirdest thing about American driving, and I know there's a lot of it, is that you can turn left at a stop sign. Not turn left at the stop sign. Turn left at a traffic-light junction.

00:02:36 - Anthony Campolo

You can turn right at a traffic light, or left if it's a yield and a green light.

00:02:41 - Christopher Burns

See, that's the thing. I'm using my UK logic because I'm thinking we're driving on the left side of the road. No, turn right. See, that's what I mean. It's crazy. And also, America needs to learn some roundabouts. They are really decent.

00:02:53 - Kent C. Dodds

A roundabout probably would have prevented this accident for sure. So I'm just waiting for cars to drive themselves and then nobody has to worry about it.

00:03:00 - Christopher Burns

Exactly. And it's just a grid of fast-moving, nonstop traffic in every direction.

00:03:07 - Kent C. Dodds

Yeah, well, it doesn't even matter to me how fast it is, because when you're not driving, you can do whatever else you want. I don't mind if it takes a while to get there because I'm already doing whatever I want.

00:03:16 - Christopher Burns

The biggest thing to get onto now is really, what do you do? Obviously, you're a big personality. You do a lot, but what would you say is the number one thing you're doing day to day now?

00:03:27 - Kent C. Dodds

My number one priority is to help people have a good experience with Remix. My official title is Director of Developer Experience. Before I joined Remix in November, I was a full-time educator teaching people how to build awesome React apps and teaching the foundational technology for a huge swath of web applications these days.

I rebuilt my website in Remix. I trusted Michael and Ryan, and they showed me demos of what Remix could do, and I was blown away. So I rebuilt my site in Remix, and I was blown away by the stuff that it enabled me to do that I'd never felt enabled to do before. I loved it so much that I was like, all I want to do is teach people Remix. Now I don't want to update Epic React or Testing JavaScript. I don't want to make a TypeScript course, which was the next thing I was planning on doing. I just wanted to teach people Remix all the time. So in coordinating with Michael and Ryan, talking about what my goals were and stuff, they said, hey, how about you just do that at Remix?

[00:04:20] And I said, that sounds awesome. Let's do that. I was really enthusiastic about Remix before I joined the company, decided all I wanted to do was teach people Remix, so I joined the company to do that.

My responsibility is to help people be as successful and effective as possible at using Remix. Where the rubber meets the road, the actual work that I do, I have been doing a lot of organizing of Remix Conf, which is coming in May. It's in person in Salt Lake City.

00:04:44 - Anthony Campolo

I think I might be there.

00:04:46 - Kent C. Dodds

Sweet. Yeah. Then I'll look forward to meeting you there. That'll be awesome.

I spent a lot of time working on that, just getting people together to talk and innovate about Remix. I also spent a lot of time helping people organize local meetups about Remix. I should have checked before, but I think we've got nine meetups all over the world that people are organizing, putting together.

I'm responsible for the docs. I'm also responsible for what our education story is going to be in the future. Just think of Epic React for Remix, that level of material for Remix that's completely free because Remix is sponsoring my time. It's my company now, so we don't make money by educating people. We don't make money anyway right now. There's no way. We certainly have plans and we're going to make this sustainable, but right now our objective is to get adoption. All of the educational material that I put together is going to be free. That's my primary day-to-day work.

00:05:35 - Christopher Burns

So simply, it's the meme where two founders are sitting there going, I can add another feature, and it's like, no, you just need to market it more and teach people how to use it.

00:05:44 - Kent C. Dodds

Our big focus right now is adoption, and we need to get people to try it because when they do, they're blown away by what it enables them to do. At least I was. So I just need to help people see what I saw when I was on the outside looking in, because it really is something special.

00:06:00 - Anthony Campolo

Yeah, it's great to see your reactions to Remix coming out and you learning it, because it reminded me very much of myself. When I discovered Redwood, I thought Redwood was so cool. I was like, this is what I want to write about. It's what I want to talk about. So I know what that was like for me. I ended up getting hired at a different company and have had to split my time. So I was never really able to fully dive into it the way you've gotten to do.

It's been really great that they got such a passionate educator to just go out there and explain the framework to people. We'd love to get first just a high-level description of what Remix is. We've mentioned it tangentially on many episodes of the show, going back all the way to episode two, but we've never had a full episode just dedicated to Remix, so we would love to get the one-on-one. What is it? What's it meant to do? What are some good use cases for it? All that kind of stuff.

00:06:46 - Kent C. Dodds

My one-liner for what Remix is, is that Remix enables me to build excellent user experiences and not feel ashamed of the code that I had to write to create those experiences.

I've built apps that have served millions of people all over the world. My personal website, which is the only sizable Remix app that I've built, serves around a half a million page views a month to a quarter of a million individual people each month. And it's like 26,000 lines of code that I've written. So it's not a small thing. And I have never been so happy with the code that I had to write to make such an excellent user experience. And so that's what made me really fall in love with Remix.

As far as the low level, or what it really is, it's a web framework focused on server rendering. Well, really, it's focused on the best user experience. So you can server render a shell and then you can hydrate a React app if you want to. That's totally possible. But because we're focused on the best user experience, that's not the best user experience. So that's not the way that people typically do it.

We server render. We take advantage of HTTP caching where that makes sense. On my website, I can't really do that because every page is unique for every user. I keep track of the articles that you've read, and I don't want to recommend an article you've already read, so every page is unique for every user.

What's really cool, though, is that I can have basically all the benefits of static site generation using HTTP caching. And then if I decide, hey, I want to have some dynamic stuff, I don't have to just do the loading spinner and client-side fetching stuff. I can start server rendering and change my caching strategy without completely re-architecting my app.

What we've found to be really effective is let's take the mental model of web 1.0 and progressively enhance it with JavaScript so that we can keep that mental model with the web. I don't want to say web 3.0, but like web 4.0, like the way that we're doing it now and into the future, where you can use JavaScript to progressively enhance things.

So progressive enhancement is a big aspect of what Remix is all about. The application works at that least common denominator of web 1.0, and then we can make it even better as you layer JavaScript on top of it.

00:08:48 - Christopher Burns

Things like server-side generation and where just React is going with suspense can seem quite scary if you've not used it or even researched it. You're just going to start sending things down a pipe without me knowing when it's done. It's like not done done. It's like, oh, this is done, that's done. Now it's all done. It really seems like Remix is taking tomorrow's concepts, where JavaScript is going, and actually using them.

00:09:14 - Kent C. Dodds

Yeah, you're referring to Suspense and React Server Components, and being able to just send things as they load. We have evaluated server components. We don't currently use server components. And there are a couple frameworks who have already embraced that and are shipping something that the React team hasn't actually released yet as part of their production offering.

00:09:34 - Anthony Campolo

Yeah, we talked to the Hydrogen team. That episode hasn't aired yet, but we get into that in that episode, which will air a couple before this one.

00:09:41 - Kent C. Dodds

Oh, cool. Yeah.

So we've actually talked with the Hydrogen team. We're chatting with them about some of the challenges that they're facing, and maybe seeing if there's a way Remix can help them with those. In our evaluation of server components, we had a version of Remix that worked with server components just so we could evaluate it, and it was not great. Server components have a really long way to go. The React team has said as much.

Personally, I'm not speaking for Remix now, I'm just speaking for myself. I'm not super confident that server components will ship in their current form because the user experience is not a great one. We'll see what ends up happening with that.

Remix can absolutely pivot and make a non-breaking change to support server components as they are today. You literally just change your file name to add .server to it, and boom, all of a sudden it's a server component.

We have a blog post that compares the current demos of server components with what you can get with Remix and React 17, the officially released React, and ours is a much better user experience.

[00:10:37] The way that we think about these problems is a lot of people like to talk about the technical benefits of things. They say, oh, well, let's do partial hydration because loading less JavaScript is good, and let's do streaming because starting that response early is good. And yes, technically those things are good, but why don't you build something with it and compare what you have with this cool new technique with what you can do with what we've got with Remix.

And when we do that, we find that potentially something like partial hydration could be a little bit better. But there are other tradeoffs beyond just the time that it takes to load.

Now all of a sudden something like Qwik. I'm good friends with Misko. I'm really excited about what Qwik is doing. But as we've built things in some of the demos and things, we're like, oh snap, now you have the app really fast and ready and interactive from the very get-go, but as the user is interacting with the app, they have to load all of that JavaScript as they're using it.

So they click on that button, and the first time they click on it, they don't get any sort of response because the JavaScript is not loaded for it yet. You have to think about the user experience from a holistic point of view.

That's what we're really focused on at Remix. Let's take these demos, let's actually build them, and compare that holistic user experience. And I think Remix is really well positioned to take advantage of these really cool new things without totally buying into them before they're ready for excellent user experiences.

00:11:59 - Christopher Burns

I think one of the perfect examples here of building something and comparing it is actually the Next.js commerce repository. I've actually used that, and I have a website in production that uses that as the base. And this was really interesting because it moved from a website that was on Gatsby. So we built the original version on Gatsby. And the biggest problem with that was that it was Gatsby 2. It started racking up more and more pages, to the point every single compiler, no matter if it was Netlify or Vercel, would just crash because it's like 20 minutes of crying.

This was at a point where it was like, what are we trying to fix here? What are we trying to solve? We want it all to be static, fast as possible, SEO, blah, blah, blah. We all like that about Gatsby. But then actually rebuilding the whole website for one product is awful.

So you go, okay, Next.js has SSG, and then Next.js brought out the CMS thing that wrapped all the e-commerce providers, and you're like, great, this is perfect. So they went down, changed it to Next.js, and there are still problems. It's not fun.

And now the problems are in a different form where now the products update every 60 seconds, great. But now every single API provider is like, why are you sending me 200 million requests a day when before you're sending me 100, because everything's now changed.

So there are so many nuances to all of these technologies. And I think the biggest thing to look at is we're seeing categories being defined without realizing it. We have Astro, Next.js, Eleventy, Redwood, but we used to say these were all Jamstack, but now I think they're not. Jamstack is a very weird term.

00:13:35 - Anthony Campolo

Remix specifically would not call themselves Jamstack because Ryan Florence has a bit of a bone to pick with the Jamstack.

00:13:43 - Kent C. Dodds

It's not just Ryan, it's Michael and me. Yeah, we are very bearish on Jamstack.

00:13:49 - Christopher Burns

This was where I was going. We used to just think, oh, JavaScript framework meant Jam, but it doesn't. Jam is not really a thing in that way anymore. And I think the biggest categories that we're going to see form are actually the technologies of how things are rendered, like partially, just fully generated to HTML, and server-side rendering.

I think server-side rendering as that, in itself, is a really interesting category where Remix has shown that first it came up and everyone was like, this is crazy. And now, as you said, you gave it a go and now you're like, why would we go back to what we were doing before?

00:14:24 - Kent C. Dodds

Yeah, absolutely. And the thing is that you can have all those same benefits of SSG with SSR because of HTTP caching and shared CDN caches. The difference is when does the build run?

I had the exact same experience as you with Gatsby with my old website, where if I needed to fix a typo on a blog post, I had to rebuild the whole thing. And because of the number of blog posts and images that I had, I would time out on Netlify as well.

The Netlify folks helped me put together a cache that lived on some Google Cloud thing, and so I would run the build. It would fill up half of the cache and then I'd have to run it again, fill up the other half, and then run it again to actually deploy. It was a nightmare.

If it was cached, I could deploy it in ten minutes, but if it wasn't, then I had to manually rerun the builds. It was a nightmare. ISR was created as a band-aid for the cut that we gave ourselves.

As cool as that is, ISR is a solution for a problem we invented, and it would be cooler if you didn't have that problem in the first place. The other problem with ISR is that it's not an end-all be-all solution. Because what if the change that I'm making actually does impact every page? Well, now I'm just back to that same problem again. Like I have a footer change or whatever. You can't escape that problem.

But the thing is, we get so hung up on these technical explanations of like this is technically better. I know that Flutter has made Dart a lot more exciting for a lot of people, but I remember back in the early days of Dart where they were saying, it's technically better, let's build it into the browser, it's so much better, and all these levels. Just because something's technically better, or you can describe something as being technically better, doesn't make it better, especially with something like a programming language.

The developer experience has a lot to do with the success of that programming language, and with a web framework, the user experience is everything. Developer experience is an input into the user experience. So it matters, but it matters insofar as it serves the user experience. Because if you don't care about the user experience, then what are you even doing? What are you building?

That's why we're just so fiercely focused on the user experience. And if there's something that we can do to make the user experience better, then that's great. We'll investigate it, provided it doesn't completely destroy the developer experience, which will impact the user experience as well.

If you want to make the developer experience better, as long as it doesn't make the user experience worse, then we'll investigate that too. I've just found that the best way to evaluate these things is to actually build it. When you build it, then you can evaluate the user experience of what you're building, and you can figure out whether it's actually better.

There's another aspect of Remix that's also really cool, and that is that unlike a lot of other frameworks, Remix is really less about JavaScript and more about the web platform. That's why we talk about using web platform APIs instead of proprietary or framework-specific abstractions. It's also why we have the data APIs in React Router, because we were going to use them ourselves in Remix.

That approach makes it so that Remix is really focused on the user experience and on the web platform. And the really differentiating part of Remix is that whereas lots of other frameworks were on one side of the network chasm or the other, so you're on the client or you're on the server and you just shoot a grappling hook to the other side of the network chasm. You might call it a full-stack framework, or just your front end to your back end or something.

Remix, instead of these grappling hooks, we built a really solid bridge across that network chasm, and so it really doesn't even feel like that network chasm is there.

[00:19:00] That's one of those things that you need to start building to really appreciate. It blows my mind every time I think about it. State management is one of the big challenges of UIs. When you have that solid bridge across the network chasm, all of a sudden your Redux store, your global application state management store, is the database.

You don't have to think about managing some sort of global store, and that just drastically simplifies things for the developer. And it drastically reduces bugs because the more code you write, the more bugs you have opportunity to slip into anyway.

As far as how it differs from other frameworks, that's probably the primary thing. Its ability to cross that network, both going from the server to the client, which a lot of frameworks do pretty well. Gatsby has its GraphQL stuff, Next has its getServerSideProps or whatever there as well, but also getting the other direction across the chasm from the client to the server, where Remix really nails that so that you don't have to think about it once you make a mutation.

Now all of a sudden you have to think about updating all of your client-side state and everything. With Remix, you don't think about that because the default with web 1.0 was that you make a mutation, you use a form that's a POST request, you're getting a full page refresh, and the server sends back some new HTML for you. And that new HTML has all the latest data. So you're basically refreshing the entire page every single time.

That's exactly the model for it. And Remix decided, hey, let's keep that model now. You don't have to think about keeping things up to date, and what you can do is if too much data is being loaded, you can opt out of specific things. Like, we don't need to reload this particular thing except in these special cases, so we'll opt out of those.

But the default is correct. And I think that is really profound. Whereas for a long time what we've been doing is our default is don't reload anything. Now our default is let's reload everything and we can optimize our way out of reloading stuff that doesn't necessarily need to be reloaded.

So the default is correct and just maybe less optimal versus the default is wrong and we have to add bugs to our app to make it right. We don't do that on purpose. It just happens naturally.

00:20:59 - Anthony Campolo

I'm glad you brought up the question of full stack and the term full stack, because that's one of the main through lines of this podcast itself. What does it mean for a framework to be full stack or a project to be full stack?

I've gone on this rant many times that I do not think of Next.js as a full-stack framework. I think of it as most of the stack, but it kind of leaves you hanging at the database level. And then I would consider things like Redwood and Blitz to be full stacks to give you like an ORM.

Now, what's interesting about Remix is you seem to be almost like waffling, but you're kind of in the middle there where you have docs for how to use Prisma and you give good conventions for it, but you don't really build it into the framework the way that, say, Redwood does. So I'll be curious. Do you think that there will ever be an ORM built into Remix, or is that something that you're always going to want to leave up to the developer to decide and just say, if you do want to do this, we're going to make it as easy as possible?

00:21:54 - Kent C. Dodds

Yeah, that's a great question. We like to refer to ourselves as center stack. That bridge across the network chasm, we really differentiate ourselves in that way. And the cool thing about that is that's the hardest part of any framework or building a web app. How do I manage this network? There are so many challenges with that, like how do you handle when the user resubmits a form or when they click on this button like 30 times? How do you manage that? We have really nailed that.

And the cool thing there is once you nail that foundational piece, then you can start eating both sides of the network chasm. We're already pretty well on the client side. There are opportunities to make components that are network-intelligent. Imagine an autocomplete component where you provide it with the URL for the resource route that serves up the data, and so now all of a sudden you have a component that understands the communication layer between what's happening on the client and what's happening on the server. So a really, really nice developer experience for that sort of thing.

And it has all the benefits of the network bridge that Remix is built on. And then on the other side of the network chasm is the server. And we absolutely will slowly eat up that side of the network as well.

Really, our priorities or our goals are we want to help developers build the best user experience possible, and if there's something that we can do to make that happen, then we're absolutely going to investigate doing that. For right now, Prisma is just amazing. If we had to do something today and say, hey, we're going to give you an ORM that's built in or something, we'd just build in Prisma because it's fantastic.

The reality is, though, that if we did that and we just said, hey, all of these things are built in, well now Remix is great for greenfield projects, but most projects that people work on are not greenfield. We want to meet people where they're coming from. That's why we didn't prioritize making Remix a greenfield project thing.

We've got 8 million apps that are using React Router, and Remix is really just a compiler for React Router and a server runtime. We were really targeting people who are already using React Router, and they need to make a fetch request to their back end, or they need to connect to some other database, or they've got their microservices or whatever they're doing. And Remix is really well suited for people who are already using React Router to migrate.

And that's what we're really focused on for the next couple of months, figuring out the various migration strategies. Well, a lot of people are comparing Remix to Next.js and we had to respond to that. And so that's why we wrote that blog post, because literally everybody, like every single live stream I did, somebody was always asking about Next.js. So we have the blog post now, go read the blog post now.

I want to talk to you about how we can get these 8 million React Router websites, like seven out of ten React sites use React Router. So much of the web of web applications are using React. So an enormous number of websites are using React Router and are really well situated to migrate to Remix. And so that's what our primary goal is.

So as far as being a full-stack framework, I see a future where we eat up more of the back end, whether those be integrated directly into Remix or like extra services or something. That remains to be seen. I think what really makes Remix special is that it's nailed that center stack.

00:25:00 - Christopher Burns

Something I wanted to touch on with the center stack is I see bridges happening right now that kind of avoid the center stack, things like React Query, things like tRPC, just to name two. Does Remix totally say you don't need any of them, even though they're great solutions to a problem? Does Remix not need something like that because it is this center stack?

00:25:21 - Kent C. Dodds

Well, I want to be careful with tRPC because I've run into some of those maintainers and they were not happy with me. So I'll just say, I don't know that library very well at all.

React Query, I'm actually personal friends with the maintainer. We go out to lunch and stuff. Well, I think he's not really a maintainer these days. Of course I am friends with the actual current maintainer as well, but Tanner Lindsley lives close by to me and we hang out. I loved React Query when it came out. I was all over it. It's part of Epic React.

If you are doing a client-side rendered app with React and you're not using React Query, then I strongly advise you to take a look because it is fantastic. It has a number of challenges that it needs to face because it is not your bundler, it's not your router, and so you have to wire things together. And that wiring is not always color-coded, if you know what I mean. So it's not always obvious what the optimal thing to do is.

In a Remix world, you do not think about managing that server-client interaction at all. And with React Query, you do. You have to think about, okay, so now I've got to have some back end I need to hit. That could be a third-party API, or it could be my own server that I'm writing. But that's like separate code that you have to go write and maintain somewhere else.

And if you need to make a change on the front end, now you have to go to that other repo, or maybe you're in a monorepo, lucky you, you've got to go to that other file wherever it is. Whereas Remix is just like, hey, we are taking care of all this for you. Here's the code for the back end, and here's the code for getting that. And you don't have to worry about any of it.

You can opt in to showing loading spinners if you want to or need to, but you don't necessarily have to for primary page transitions and things. Yeah, Remix manages all of that for you.

[00:26:55] And so the other thing is Remix is built with the platform in mind in a way that a lot of frameworks are not. Just as an example, there are a lot of things that I'm thinking about when I say that. One example is the request response objects that you're interacting with are all web Fetch request/response objects, not some sort of special abstraction around it.

That's the one thing that Remix does a lot. Rather than abstracting around web platform APIs, we take a step back and we expose web platform APIs for you.

Another example is when the user is navigating around the page and they go to click on something. We can prefetch everything for you because we're your bundler and your compiler. And so we know exactly the CSS and the JavaScript and the data that you're going to need. When the user gets over there, we start prefetching it. And the way that we do that is with link prefetch tags so that we're just using the platform. So there's not a whole lot of custom code that we've written to be able to do that.

Prefetching, when you are not the bundler and the router, is a lot more tricky. React Query could not do that. You as the user have to say, okay, go prefetch this. But also because it's not the web platform, you're also kind of stuck because you're prefetching that and loading that data, just the data, not the CSS and JavaScript, just the data portion into an in-memory cache that's managed by React Query.

So what happens if the user hovers over the link and they're like, I'm going to go here and prefetch it. And then they say, never mind, I'm going to close the browser, or they hit the wrong button or something. So they open up the browser again. That prefetch cache is totally gone because it was in memory and you closed it, or you refresh the browser or whatever. If you're using the platform, then that prefetch cache is living in the browser's prefetch cache, which is not in memory. All of that prefetching that you did, all that work is still available and there.

And on top of that, if you're managing that in your own in-memory cache, now you have to start thinking about, well, what happens on a lower-end device that has less memory. Well, now we got to start thinking about garbage collection and everything. Browsers already do all of that.

So if you just use the platform, then you don't have those sorts of problems that you have to start thinking about either. I often tell people they'll say, hey, I really like Redux, or I really like React Query, and I'm using that now. Can I use that with Remix? And the answer is, of course you can. Yes, you absolutely can.

I used to just say you don't need it and people would get confused by that. So now I just say, yes, you can. And I watch them as they bring all that stuff, and then they realize they don't need it themselves and they get rid of it and they're like, oh, you're right, I don't need this. Yeah, we don't need tools like that. Remix manages that for people.

00:29:11 - Christopher Burns

I did want to go back to what we spoke about just before this. You were saying that there's, I forgot the numbers, I'm terrible at it, so many React apps out there that use React Router. Does this mean that none of them are actually using things like modern frameworks, like we see them, like Next.js, so that they're more the classics of Create React App? And then do you see Remix as a Create React App replacement?

00:29:37 - Kent C. Dodds

Yeah, great question. Yes, that is the case. Twitter would have you believe that everybody's using Next.js. NPM stats tell a different story, a very different story actually. Like Twitter would have you believe a lot of frameworks are really popular, but npm download stats are not reliable. We all know this.

But one thing that is pretty reliable is DevTools installs. I don't build apps with Svelte, so I don't have the Svelte DevTools installed in my browser. I think that makes sense. Folks who are using the DevTools are probably developing with those frameworks, so that's the best metric that I can think of.

And if you look at those metrics, the last I checked, React was almost three times as widely used as all other frameworks combined, and two years ago it was only two times. So it's actually increasing. It's huge. React and React Router are an enormous part of building modern web applications today.

As far as being a Create React App replacement or a custom Webpack replacement, yes, that's exactly what we are trying to say.

[00:30:32] We're happy to be a Next.js replacement too, if people want to switch over from Next to Remix, but that is totally not our target. We're targeting people who are doing their own version of server rendering with React Router or Reach Router as well. Reach Router is like a sort of a fork off of React Router, and Gatsby is probably the main user of Reach Router.

The biggest challenge for people migrating from client rendering is figuring out how to host a server. But most of those people who are doing that are at companies that are already hosting servers because you've got to have a backend, unless your app is 100% client side, like 100% client side, no backend. There aren't many apps like that. Most companies have a way to run a server, and that's what we're just trying to help people figure out.

00:31:12 - Anthony Campolo

Yeah, you say this is a good segue to what I wanted to touch on a little bit before we close out, which is it seems like along with having this web fetch API and leaning into the platform, you also are setting yourself up pretty well for this new school edge thing that Cloudflare Workers and platforms like that are doing. But at the same time, you have run your own blog on Fly with Docker containers, and I'd be curious if you were evaluating one or the other, or how you think about when to use a persistent server versus leaning more heavily into these more edge-native type solutions?

00:31:49 - Kent C. Dodds

Yeah. So when I was building my site, one of the big important things for me was I wanted to make my site fast all over the world, no matter where you were. I started with Firebase for my authentication. I was like, oh shoot. If I'm using Firebase for auth, they have to go wherever, whatever region I've chosen for Firebase. That's no good. And I was also going to do the same for my data.

Well, it doesn't matter if I deploy everywhere in the world. If my data happens to be, I mean, it does help, but it's limited on its ability to help with the performance of my app. I started evaluating solutions for doing authentication and data storage, as well as deploying my app to multiple regions throughout the world.

At the time, Cloudflare Workers was the big name in that, and I heard about Fly, which also has multiple regions all over the world. The difference there is Cloudflare Workers is a somewhat constrained environment for JavaScript, whereas Fly is like a full Docker container. They deploy it all over the place and they'll call your Docker container with whatever HTTP traffic comes in.

I evaluated Cloudflare Workers a lot. The biggest challenge that I ran into is I actually use esbuild at runtime to compile my MDX blog posts, and then I also use ffmpeg at runtime to generate podcast episodes for the Call Kent podcast, where people can record themselves in the browser. They save that recording to my database, and then I record my response, and then we stick those together with ffmpeg.

There is an ffmpeg wasm. There's an esbuild wasm which can run on Cloudflare Workers, but it wasn't quite suited because Cloudflare Workers is really supposed to just be a really fast response sort of thing. And I probably could have made it work, maybe have another long-running server that's managing that portion, and the rest of my site is on Cloudflare Workers or something, and some people have actually done just that.

But I went with Fly, and I'm really happy with that particular solution. I also can do a long-running database connection with my Postgres database, and Fly also has read replicas automatically for Postgres.

So I've got a Postgres cluster that has all of my regions supported there. They do the same thing with Redis, and so I've got a Redis cache because I don't want to compile my blog post every time somebody goes to that blog post. So I just put it in the Redis cache.

Now my blog is served to people in like 250 milliseconds or less wherever they are in the world. And that's like hitting the server and coming back. No CDN, HTTP cache going on, which is fast enough for folks. And I've done, like, the WebPageTest.org on my website all over the world and compared it to Amazon.com because I figure if I can be as fast as Amazon.com, then I'm probably okay, and mine's faster, so I'm probably not doing as much. But they have a lot more engineering budget than I do for my personal site.

I think that if people want to go with edge computing, Remix was built with that in mind. That was a really important aspect of what Remix was doing. That's a big reason why Remix went with the web platform APIs for request response headers, URL search params, all of that stuff, because we were targeting Cloudflare Workers in particular.

Because of that, we'll be able to target service workers in the future. And so you can have a completely offline app with Remix, where Remix is just running in the service worker, which would be a really interesting future. And then on top of that, we have some experimental support for Deno as well, by not being super tightly coupled to Node in particular. Wherever you want to deploy your JavaScript backend, you can use Remix for that.

00:35:02 - Anthony Campolo

I also heard some very brief rumblings that it could potentially one day be possible to use Remix without React.

00:35:10 - Kent C. Dodds

First of all, it's really cool that we can do all the server rendering. We can send a response in some cases, like we've had Cloudflare Workers respond with a cache miss in 20 milliseconds, rendering a Remix app. We've had the same thing with Deno actually on Fly. So you put Deno in a Docker container, put it on Fly, 20 milliseconds response time. When you get that fast, it's like, okay, what are we even doing here? It's hard to optimize that even further. Of course, those were pretty simple apps and everything.

You add layers of caching for any data that you need or whatever, but anything sub-second or sub-100 milliseconds is pretty dang fast. So I wanted to establish that we can get the HTML on the page really fast, and then the JavaScript follows along. And because we support all web 1.0 stuff, the JavaScript doesn't have to be there for the app to be functional.

And when you get into that world, then the amount of JavaScript you send still matters. But it matters a lot less because the user can actually start using the app while the JavaScript is loading. But it does still matter. We don't want to just send them megabytes of JavaScript.

So supporting Preact is our main driver for that. We want to be able to support React as well as Preact, and then when we have that done, basically what that's going to amount to is we need to have a router that's just the Remix router. We use React Router right now. We're going to have a framework-agnostic router and then just have a React adapter for that, and then we'll have a Preact adapter for that.

And that's as far as we're going to go, I think, unless we can see something that's just an obvious choice for us to support. But once we have those, then it should be pretty straightforward. My guess is those are going to be a couple hundred lines of adapter code. So once we have those as an example, then yeah, sure, bring along your Angular, bring along your Vue, bring along your Svelte, whatever.

And it should be able to just hook in with those. So it's not really a huge priority for us because, like I said, React is way more popular than Twitter would have you believe. I think it's pretty interesting that we'll be able to support other frameworks in the future, but yeah, not a huge priority for us right now.

00:37:04 - short split/interjection

I thought it was really...

00:37:05 - Christopher Burns

Interesting that when I read through the home page and started reading through the documentation, it kind of hides the fact that it's a React framework. It said it once on the home page outside of a testimonial. I think that it's React.

And also you don't import from React for things like useEffect; you import through Remix. When we talk about these abstractions, is it that thing of not, we know better, developer, but we should just trust that, yes, while React is amazing, whatever Remix is importing is going to be the best that it can be?

00:37:39 - Kent C. Dodds

There are a lot of things that you import from Remix, like everything from the router. We re-export everything from the router, and sometimes in some cases we wrap those. You do not import useEffect from Remix, though. That will come from React, as well as useState and everything.

So we don't necessarily hide the fact that we're using React. And if we do end up supporting other frameworks, you're going to import things from those frameworks. But we really don't like being classified as a React framework. We are a web framework because so much of what we do has nothing to do with React.

Like 80% of Remix is completely framework agnostic and the 20% is just the router, which we're going to make framework agnostic as well. Again, our target is React Router users. We don't want to be completely tied to React because so much of what Remix is has nothing to do with React.

00:38:26 - Christopher Burns

I think that's a really interesting philosophy on the whole framework. It's not necessarily following the path that Next.js is following. You know, Next.js is, if you believe what Twitter says, the thing that murdered Gatsby, and now it's waiting for the next thing to try and murder it, but it's still sitting on top of the food chain.

But in all essence, most companies, most products, they never even move away from Create React App. It is just what they use. Just a quick one-off question. I think with Remix, what is the goal? As in, what's the starshot moment? Is it that Remix is standalone, everyone has stopped comparing it to Next.js, and it's just standalone? Or is it that it's just the best that it can be?

00:39:10 - Kent C. Dodds

The end game for Remix is that the web is better than it was when we started. Ryan, Michael, and I will often say that we're just sick and tired of using our kids' school websites because they're so bad, so we want to make the web better.

For Ryan and Michael, it's especially potent because they will be using these sites and they're like, man, what garbage is this? It's so bad. And then they'll pull up the DevTools and see that they're using React Router and they're like, I did this.

They just want to make it so that people can build web apps with their software, and the web apps that they build are, by default, really great. That's our goal: to get all these people that are using Ryan and Michael's software already and have them upgrade to Remix. Really, Remix could be called React Router V7. It really is so much just an upgrade of React Router.

The goal there is to take all the React Router users, upgrade them to Remix, and then demonstrate for other folks that are building for the web that Remix is a really awesome way, both from a user experience standpoint, but also a developer experience standpoint, to build modern web apps.

The end goal there is to get people to build better websites, sometimes with Remix, and eventually Remix. We expect to eat up more of what it takes to build a web app.

00:40:19 - Christopher Burns

I can see a lot of success from just taking Create React App, slowly converting them to the new happy path of Remix, and then literally going, so this next big feature update, no matter what it is, has added this without you needing to do anything. And you go, oh my God, that's so cool.

You know that's a slow transition because at the end of the day, rebuilding something in a different framework is detrimental. No business person would say, yeah, we should spend $100,000 on converting it from Gatsby to Next.js. That is perfect. Thank you for requesting that. That just doesn't happen in the modern world.

00:40:56 - Kent C. Dodds

Yeah, absolutely. There are some cases where that's absolutely necessary, like the case you described where we are getting more and more products. That's more and more pages. We can't be doing this. So sometimes it becomes an existential crisis moment where you're like, oh shoot, we've got to make this pivot. We made a mistake in our choice, and we are absolutely happy to be there for those folks. But again, it's mostly we're focused on people who are using React Router.

00:41:20 - Anthony Campolo

Awesome. Well, thank you so much, Kent, for being here. It's been a really great conversation. We are happy you're still here and alive with us all. Why don't you let our listeners know where they can find you on the internet and where they can find Remix?

00:41:32 - Kent C. Dodds

I am at Kent C Dodds pretty much most everywhere. You can find everything at kentcdodds.com and Remix is remix.run. Scroll down to the bottom, you'll find a link to our Discord and Twitter and YouTube and all of that stuff there.

There is a really great Getting Started guide. We actually have two tutorials. One that's like a learn most of Remix or most of the concepts of Remix in like a half hour, and the other ones are like really in-depth, like let's build our own authentication and let's create our own database and all of this stuff with an optimistic UI and everything. We build an app together.

So if people want to learn Remix, then we've got some really good things for you and a lot of really awesome things coming. Definitely come to Remix Conf in May. I would love to see you in person in Salt Lake. And definitely join our Discord as well. We have a really awesome community there. We'd love to see folks there.

00:42:15 - Christopher Burns

Thank you for your time today.

00:42:17 - Kent C. Dodds

Thank you. Appreciate it.

00:42:48 - Anthony Campolo

Cool.

00:42:49 - short split/interjection

And...