Kent C. Dodds (00:00):
Hello friends. This is your friend, Kent C. Dodds and I am joined by my friend Ryan Florence. Say hi, Ryan.

Ryan Florence (00:05):
Hi Ryan.

Kent C. Dodds (00:06):
Oh, good one. Yes.

Ryan Florence (00:08):
How many people made that stupid joke?

Kent C. Dodds (00:10):
No, it's perfect. The entire season I've been making that joke and three people got it. So, good job. So, Ryan and I have known each other for a long time. We were both in Utah. He left for a while but he's back. And we met, I think, for the first time at a meetup. I think it may have... Was it an Angular JS meetup? I don't know.

Ryan Florence (00:34):
My memory was, it was my first React workshop I ever did and you were in the front row.

Kent C. Dodds (00:39):
Yeah. Well, I remember... I feel like I met you before that.
But in any case we... because I remember standing in parking lots after meetups chatting with you and-

Ryan Florence (00:49):
I never went to a single Angular meetup so it wasn't that.

Kent C. Dodds (00:51):
Yeah. It must've been a React meetup then.

Ryan Florence (00:53):
We did the Utah JS things too.

Kent C. Dodds (00:55):
Oh, yeah.

Ryan Florence (00:56):
Probably one of those.

Kent C. Dodds (00:57):
This was back in 2014, 2015 timeframe, right when I started getting into React at the end of 2015. Well, sorry. I started working in React at the end of 2015. I started playing with React in 2015, but you were much earlier... Well, right. You were much earlier in the beginnings of React, 2014, maybe 2013. Is that right?

Ryan Florence (01:21):
I ignored it for a year. I was putting all my bets on Ember. But anyway, switched to React. It'd been out for about a year when I really started looking at it because we were hitting some major performance issues in her app and React solved them.

Kent C. Dodds (01:40):
It was a miracle. And early on, you gave the talk that ... I can't pronounce it. But what was it like reacting Angular?

Ryan Florence (01:50):
Embularactymerbone. It was a JS comp 2014. That was right in the middle of my transition just a few months earlier. I had been speaking at Ember column about Amber components, and what you could do with them, and how they can encapsulate state and talk to each other through events and all this stuff, which is basically a talk about React in Ember. But I didn't know it at the time. I hadn't even touched React yet. And then right after that talk, I started goofing around with React and I was like, "Oh boy, this is exactly what I've been wanting out of these components." And yeah, anyway, they asked me at JS comp to give a talk on all of the frameworks, kind of compare them all. And so, yeah. Embularactymerbone. Ember, Angular, React, Polymer, Backbone.

Kent C. Dodds (02:42):
I missed the Polymer in that title. But yeah, that's great.

Ryan Florence (02:46):
That's the mer part. Embularactymerbone.

Kent C. Dodds (02:49):
Oh, there you go. Cool. [crosstalk 00:02:52]. Yeah. I had a slightly similar experience with Angular JS where I made directives like as one does. I spent most of my time making directives that were basically components. This was before Angular.component was a thing. And that was just what I wanted. And so, when I started playing around with React, it was very much like, "Oh, okay." So, this is-

Ryan Florence (03:17):
This is what I was chasing.

Kent C. Dodds (03:19):
Yeah. Yeah, exactly. And I spent a lot of time with my forms library, trying to push more and more of my stuff into JavaScript rather than the HTMLs, and DSL and stuff. Yeah. React was just a breath of fresh air, but we're getting ahead of ourselves. I want our audience to get to know you a little bit, Ryan. So, can you give us an intro to yourself as professional and personal as you want? Just, we want to get to know you.

Ryan Florence (03:46):
Sure. Hobbies. I grew up playing soccer, snowboarding, skateboarding, wakeboarding, anything on a board. It was fun. Actually, wrote in some wakeboarding tournaments and stuff. I wasn't a pro or anything, but I could do flips and stuff. Not anymore. I'm too old. That stuff hurts when you wreck. Gave myself a few concussions. So now, I always have a helmet on no matter what I'm doing. And then, played a lot of music, played in some bands, recorded some CDs. I bring in the music because music, I feel, has a huge influence on my coding and what I enjoy most about writing code. And that's the composition of it all, how you put a song together, how does the melody match with the chorus, and when did these instruments come in, and all that kind of stuff. And code to me feels a whole lot like writing the song.
And then, as far as professionally, I actually started doing web development as my first job. I'm 40 years old right now. So, that was quite a while ago when I was a teenager. And it was before JavaScript was invented, before CSS was invented. We just had HTML. And, it was wild. If you wanted to change the font, there was literally a font tag where you would change the font. And then you'd say face equals Times New Roman, or Verdana was actually what we did all over the place, Verdana and Georgia.
Yeah. So I was a teenager, I was mid-nineties and I just built websites for my band, the bands that we played shows with, built everybody's websites. And that's why they let me play shows with them is I built their websites. And then, I did that for a bit. My dad invested in a what'd they call those, an ISP. Internet service provider. When you used to have to call with your modem and you'd take over the phone line. And then, you're trying to download a picture of Kurt Cobain playing live somewhere, and your mom picks up the phone and kills the connection, you're like, "Mom, no." I've been downloading this for 32 minutes. And then, yeah. He invested in one of those. And I started to build websites for them. They paid me $9 an hour, which back in the nineties, for a 15 year old, 16 year old, those was decent money.
So, yeah. And then, we had this thing called CGI bin and that's where you kind of think of that as API routes now. We call it an API route. That was your CGI bin. You could run scripts there. And then, I quit doing web stuff, went to college, studied economics, got a degree, went into retail, finance, insurance and junk. And then, somehow found my way back over to web development. And yeah, I worked for agencies doing credit card websites for Capital One and internal emails for Visa and just any kind of client work, and then got a job at Instructure who builds canvas LMS. And that's where I got a lot of my dev experience. Was working there for several years on a huge app. If you're familiar with Rails, you can type rake routes, and it will tell you all of the routes in the app. And there were about 2,500 routes in this app. So, it was a pretty large app.

Kent C. Dodds (07:26):
I used it. So, I know there's a lot to it.

Ryan Florence (07:30):
Yeah, there is a lot to it. And, everybody's kids are now using it, especially after the pandemic and everyone going online school started gobbling up canvas. So, worked on that a lot. And then, got into React, really enjoyed it and found a little business with my partner, Michael Jackson, to go and train teams on how to get the most out of React. And we've been doing that for the last five, six years. And then now, we're working on a web framework called Remix. The idea is, it kind of mixes all that old stuff from when I was a teenager with all the new stuff that we're doing now in React and trying to get the best of the web, the best of the core pieces of the web, but also do all the cool new tricks that you can do with JavaScript. And sometimes, it feels like those things are opposed to each other, but we think we've done something kind of cool in Remix that gives you the best of both worlds.

Kent C. Dodds (08:30):
No, that's awesome. Anybody who has been listening to the show or knows me at all knows that I am really looking forward to chatting with you about this because I just, I love Remix. I've been playing around with Remix since ... Well, even reading what you've been writing about it since you first got started.

Ryan Florence (08:51):
I left April.

Kent C. Dodds (08:52):
Yeah. So it's been a long time and it's just fantastic.

Ryan Florence (08:57):
You're excited about it before it was even for sale. Because if I remember correctly, you bought a ticket, or not a ticket. You bought a license before I even got to run through my testing the production website. I had no link to the buy page on the website, but I deployed it with no links. And I guess you just type in slash and buy it.

Kent C. Dodds (09:18):
Yeah. Somebody in my Discord shared the link and they're like, "Hey, look, you can buy it now." And, it was the day of, I think you were going to launch in 20 minutes when you [crosstalk 00:09:28].

Ryan Florence (09:27):
Yeah. I had just deployed it. And, I went and grabbed myself some breakfast. And then, I came back and I went through the little checkout flow to make sure that it really worked. And then, I was going to deploy again with the link on the homepage and people were already buying my test license for $1.

Kent C. Dodds (09:46):
Yeah. I still have that license on my dashboard.

Ryan Florence (09:49):
I know. I need to go. Yeah. So, when our customers log in to remix.run, they get their license key in there and it lists any license they have. So, there's a handful of people that all bought this funny $1 license.

Kent C. Dodds (10:03):
Yeah. That was funny. Yeah. So anyway, I've been really looking forward to Remix and just what it can do, but I think we want to talk more broadly about the web in general, not to say that people shouldn't check out Remix because they absolutely should. I think that, of all tools available, it brings people the closest to being able to build better websites than anything else that I've used. But, there are some foundational principles that Remix built on top of that, I think, is what makes it so special. And I'd love to chat about what some of those are like. What are some of your guiding principles? And, yeah. I'd actually like a bit of a history lesson from you since you have so much experience, how did we get from building, just putting a PHP file out there to building full client site? Everything is in the client. We're just doing JavaScript for all of the things, and then coming back to Remix where we're letting the browser do what it does well again.

Ryan Florence (11:07):
Sure. Yeah. So I guess, if you talk to web developers who are around my age, a little older, a little younger, a lot of us came into web development with PHP. And with PHP, you can honestly think about it like serverless functions. So, if you're familiar with serverless functions, you can just deploy a JavaScript function to AWS or Azure or Marcel or whoever, and that has a URL associated with it, and would that you're all gets called it. You don't have your own server. Amazon is running a server that just brings in your function and calls it whenever it needs to.
And PHP was a lot that way. You had your web server on some web host that was running PHP. You didn't have a PHP server. You didn't initialize it or anything. It was just, you clicked a couple buttons. And it was like, "Okay, now I got a PHP server thing," and you could upload through FTP, file transfer protocol. You just put some PHP files up there and you could execute code. You can write logic to kick out HTML. You can go talk to a database, go ask your database for some data and then loop over that array and then echo out some HTML based on that data. It actually feels a whole lot like a React component, except for you wouldn't need use effect and stuff. Just at the very top, you can be like, go to the database, get some data. Okay. Now, map over this thing and then kick out some elements.

Kent C. Dodds (12:40):
Yeah. That's a single file component to the max.

Ryan Florence (12:44):
Yeah. And back when I was doing PHP for my own stuff, it was just like, I didn't have a whole lot of structure. I just put a file up there. That was my route. And at the top, I'd make my database query, top of the file. Underneath that, I'd iterate through all my data to kick out HTML. And then down at the bottom, I just put a script tag to add dynamic behavior to it. And then, if I had a form on the page, I would just post, form method post, and it would post to that very same file. And at the top of the file would ask if HTTP method is post. I think, it was dollar underscore post. If I had anything in the post, then, "let's go to the database and then redirect right back to this page." But if I didn't have a post up there at the top, then it was a get request. And so, I was just going to get the data and display it. So, I had all this stuff just in this one file. And a lot of us built stuff that way.
You asked how we got from there to where we are. I don't know. It's all sort of such a blur. It's [Ajax 00:13:59]. Ajax basically was invented by i6, 5, 6. It was 95 XML HTTP request for Outlook Express, an email client. This is my memory. It could be wrong. But, I remember learning this at some point that they were building Outlook Express. And instead of doing a full page reload to go and check your mail, because it's your email. You want stuff to show up as it arrives. The Microsoft team was like, "We want to wait to go and talk to the server without unloading this whole page." And so, they came up with XML HTTP request. So, that allowed the browser to say, "I'm just going to make a little request, not for this new document. I'm not going to change the URL or anything. I'm just going to go off to the server and ask for some information."
They were transferring XML, not [Jason 00:14:57] at the time. And then, the XML would come back. They'd know what the new messages were. And then, they could use JavaScript in the browser to render new messages, and everything else in the UI as well. Now, instead of having to click a link or submit a form to change pages and change URL, you can just go to these little operations with the server. And then, just kind of went from there. We started building apps this way. And then, we started to want to be able to change the URL without unloading the whole page. So, the app got into some sort of state and then you'd say, "Okay, let's go change the URL because we just clicked on the compose button or something like that in an email client." So compose, well, the URL should say compose, but we don't need to unload this whole page. We can just use JavaScript, remove some pieces, add some pieces.
And that removes some pieces and add some pieces is where it starts to get really tricky. We had. And that's where jQuery, and MooTools, and Dojo all started to show up in this phase where the user interacts with a piece of the UI. You don't want to load the whole page. We just want to go and change a little piece of it. jQuery, I think, stands for JavaScript query. You're going to query the page to find the element you want to manipulate, change its attribute, hide it, remove it, animate it, and you pass this CSS selector to find it on the page. So, document.queryselector and query selector, all didn't always exist. We got that from jQuery.
And today, you've got all these tricky bits of the user interacted, I need to go find some elements. I need to go change them and change the state of the UI. And now, they click something else and I need to go change this other piece of the UI. And, I hit this hard at a job that I had a long time ago, building. It was a microcontroller website. What was the company? [Atmill 00:17:02]. Atmill has a whole bunch of microcontrollers. And, we were contracted to build this, it's pretty normal now on websites. But back then, it was a pretty big deal. A little sidebar that had a whole bunch of filters on it like check boxes for what type of controller you want, how many pins it has.
And as you interacted with that thing, I needed to go make HTTP requests for data and then update the screen with those results. This is like, React 101 now. It's so easy, but it was dang hard before because we didn't, we weren't really programming in the browser with this idea of this state that drives the UI. You just had the UI. And when anything happened, you'd go and you'd grab pieces and delete them. And then, you'd build pieces and inject them. And you just cross your fingers and hope that you made the UI look the way you wanted it to look.
So, it was a lot of that kind of stuff happening. A lot of [dom 00:18:08] manipulation is what we call it and that got really hard. And so then, we got things like Backbone JS and Knockout JS that had this pub sub idea where you'd say, "Okay. Instead of in our click handlers going and grabbing pieces and manipulating them, let's just emit any event." We're going to have some other code that listens for that event and responds to it or reacts to it. That got tricky though, because you've got all these global topics or channels that you're broadcasting and it was hard to see where the code connected. And, the next generation that we saw was when Ember, and Angular, and React popped up. And instead of being dom manipulation or broadcasting events, you had this idea of state. You'd say, "Here is the state of my app."
And then, you would just inspect and iterate that state to kick out your HTML. Well, that sounds 10 minutes ago in this conversation. PHP. You'd go to the database, get your data. And then, you did your data and kick out your HTML. So now, we actually had that in the browser with these new frameworks where I've got this state. I got to go get it from somewhere, but I've got it. And now, I can just look at that state and kick out HTML. But, the framework is going to do the dom manipulation for me. And so, my whole career has felt like I started in this kind of, well, I started before PHP. I just did plain HTML, but when I really started programming real websites, not real websites, websites that had databases and had changing UI. I guess, more complex websites. I feel like I've been chasing that PHP dream the whole time and all the tools that I really enjoyed gave me that feeling.
And React was one of those things that gave me that feeling of the old PHP days. I got data. I map it. I look at it. I kick out HTML and I'm done. But, as we've gotten kind of back to that, I think, we've kind of gotten away from some fundamental pieces, like HTML and HTTP, with the post thing. I was talking about it in PHP. It would be cool if our React components could say, "Oh. Hey, did they just submit a form?" It's a supposed, should I go right to the database and then redirect you to another page? Or is this a get, and I should display the page and have all that code and capsulated in the same spot rather than ... Oh, well. Here's my JavaScript code. And then I've got this API route over here, that's in node or some other language. And I'm going to make fetch request to that thing and then come back and update stuff. But that code is very far apart from each other.
And I guess, coming full circle to where I'm at now, what we've been doing with Remix is trying basically to get all the cool benefits of today of a highly dynamic page, form validations that are animated in, and comments that show up right there in place, scroll positions, getting, working the way they should, and tabs, and drop downs and auto completes and everything we'd like to do with a lot of JavaScript, but still have that same feeling of simplicity that we had with PHP where it's like, "Here's my data. Here's my elements. If I want to change the data, just check if there's a post, if there's a post change the data, and then we're going to go right back to this page and see it update." So, Michael and I with, with Remix, we're trying to remix that old web that we loved with the new stuff in React. That was long. That was the whole episode.

Kent C. Dodds (22:01):
That was great. I think there are a lot of things in there that are telling of our current state of things. In part, I feel the power and flexibility of JavaScript. And when we got [inaudible 00:22:15] requests and different things like that, like Ajax, and then now we have the fetch API. So it's even easier that it's become a really easy for us to do everything in the browser, everything with JavaScript. And so, we can store state and variables and we can re-render these things. And it's also declarative and it's really nice, but lots of us find ourselves re-implementing what the browser supports by default, just because we can, and we don't have the background to remember now. Wait a second. The browser already does this. I didn't go through a boot camp, but I know a lot of bootcamp grads who never really got a lesson on the fundamentals of HTTP, for example.

Ryan Florence (23:02):
They don't even know that a form can submit itself.

Kent C. Dodds (23:04):
Right. Yeah. They just learn events.prevent default. I don't know why I do that, but then I can do that stuff.

Ryan Florence (23:11):
Yeah. I'm going to go parse the form and I'm going to serialize it into something and I'm going to make a fetch. Well, forms already know how to do that all by themselves.

Kent C. Dodds (23:19):
Yeah. Exactly. And so I feel like, what excites me most about Remix is that, whereas all other frameworks that I've used up to this point and not just like frameworks, but the meta frameworks built on top of React. All of these have continued this pattern of taking what we can do with JavaScript and just making it bigger, making bigger [crosstalk 00:23:49], making it do more for me. We've got Apollo and we've got React query, which I love. It solves many problems. All of these tools, they solve real problems. I'm not saying that Apollo is unnecessary. There are problems that it's solving. What I love about Remix is that it goes back in time a little bit on some of these things and eliminates the problems altogether by using the foundational pieces of the web that the web has always been good at.
Even when you were first getting started with PHP, HTTP understands these types of requests and you can make a form that makes this request, and not that we want to keep doing full page refreshes. There was a reason that Ajax was invented, but we can mesh these in a way that eliminates lots of the problems that these tools were built to solve so that you don't have to worry about solving them in the first place. And then, also it gives you the cool flexibility that you need for accessibility or that you want for a better, more dynamic web application.

Ryan Florence (24:52):
Totally. A good example of this is, it's right at the end of our Remix beta live stream that Michael and I did. We're kind of show at the very end. There's this common problem in a React app where you've got some data on the page on a sidebar. And then, you've got the main screen that has a button or a form or something on it that manipulates that data maybe to just ... In our live stream, it just added a task to a list. And on the left side, you got a list of all the projects and they have little counters next to them. How many tasks there are and how many are complete?
And if you don't have any JavaScript at all, and you've got this UI, so you're just doing PHP days. When you create a new task, you're going to get a full page reload. And on that full page reload, that new screen, so you're going to look at the post and you're like, "Okay, let's make a new task," or "Let's make a new project." And then, you're going to redirect right back to the same page that you're at. And now, it's going to come around for the get, and it's going to go to your database. And it's going to read the current data, all the fresh stuff. Then, you're going to get a new render with all of those items on the page now, on the left sidebar and in the main area that you're looking.
And so, when we build features in Remix, we always have two tests. We have a bunch of puppeteer tests to test from end to end that these apps and these APIs work the way we think they do. We're actually looking at how many HTTP requests, puppeteers observing in Chrome and what type of requests they are and what the URLs are to really make sure that we're doing what we think we are. But there's always two tests. One is a document request tests. And one is a script request is what we call them. So, that just depends. Do we have JavaScript on the page and we're navigating with React router or do we not have JavaScript on the page and are we just navigating with the browser's built in stuff? And so, every one of our features pretty much is not just built on the model of HTTP, but it actually is HTTP. Our core features of Remix work with JavaScript or without it.
And the whole point of Remix is to just emulate what the browser does so that we don't need those full page reloads. But programmers get to just develop with the same mental model as if there was no JavaScript on the page. So, the way that this plays out in Remix is every route. If you post to that route, which is just for method posts, you don't do a fetch. You just make a form. You can have JavaScript off. There's no JavaScript on the page. We will post to that route. We'll call your action, which is an export from the component. And, you do your data mutation there, and then you redirect back to the same page. And now this time, it's a get, so we'll call your loader, which returns the data. And then we'll render the React component. And you don't even need JavaScript in the browser for this to work.
And, the whole screen will update, right? You make a change on the main page. The left sidebar data updates without having to do anything because there's no JavaScript. It's just, I'll go into the database. I'll go into the server and it's re-rendering whole page. So, the same interaction. And when you put JavaScript on the page, you don't have to change the mental model in Remix. You don't have to refactor your code or think about it any differently. Remix now just emulates what the browser does. So, when you have a form that posts to a route, we automatically know you're probably mutating some data. The browser would do a full page load on this, and you would get all fresh data. So, we are going to fetch the data for every layout that you have on the page.
And that way, you have a form deeply nested inside of your UI. And then, you have data that it affects way outside of the top of your layout. That's going to get up to date without you having to do anything about it, because we just emulated what browsers do with forms and HTTP. And, it's kind of those things where it's just like, "Oh, whoa. This is way easier."

Kent C. Dodds (29:07):
Now I don't have to worry about caching.

Ryan Florence (29:10):
Yeah, you don't. That's the thing. You're bringing up React query and Apollo and stuff. A lot of the things that those tools do is they try to make sure I already have this data on the page. So on this next React tree, we called set state somewhere, right? Someone called set state. We asked for this data, and then these clients I tools are like, "Well, do I already have the data or not?" And now I'm going to only fetch the pieces that I need. Now, I need to expire all of those things because I may have just changed it.
In Remix, you just don't even have those problems because we emulated what the browser would do. And, we know all of your nested routes. When we use the word route, it's different than what a lot of people think of. So, layouts, all of your nested layouts, each layout can say, "I need this data down the whole tree." And we can look at that. We don't need something like a React query or Apollo to optimize our queries. We just know looking at the route and the layouts We go, "Oh, hey. You know what, this layout's not even changing, so we don't need to refresh that data." And this layout is not changing. So I don't need to refresh that data, but this layout did change. So, we're going to go and call the loader for this layout.

Kent C. Dodds (30:20):
As well as parents.

Ryan Florence (30:23):
Oh, not on a normal navigation. We don't fetch the parent. Yeah. We only fetch this [crosstalk 00:30:28] that's changing, which is why we don't need a big client side cache. It's just the pieces that we need. But, yeah. I think what you were thinking was then when you submit a form and we say, "Okay, let's recall everything because you might've changed something," but you don't have to worry about which keys do I need to expire? Which thing might've changed? We actually just had a customer this morning who was saying, "Hey, my route loader, the data never changes. It's always the same. It's just my environment variables like a Stripe ID." What is it? The striped public key and that kind of stuff.
And they're like, "It never changes, but Remix keeps fetching it whenever I submit a form." So he said, "Well, put a cache control header on that loader," which is an HTTP idea that browsers understand. You can tell a browser, "Hey, if you make this request, it's got a max age of an hour." So if my code tries to request this another time, just bring it from your own cache. Don't even make the request. So, your code still pretends like it's making the request, but the browser just pulls it from disk or from memory. And so, we have these tools. Yeah. We have these tools in it.

Kent C. Dodds (31:39):
[inaudible 00:31:39] going to gush over that. I just love that. Yeah. So, this is one of the things that I've really appreciate about Remix in general is just that it's forcing me to spend a lot of time on MTN. It's like, I have to learn about headers and I have to learn about request and response and HTTP to be able to use Remix effectively. And, when I created React testing library, that was one of the big appeals there too, was that, we didn't create a bunch of extra APIs for you to go learn. We don't have this special find by component name or any of this weird stuff. We just give you dom nodes and you do what you want with dom nodes. You want to learn how to interact with Dom nodes, go to the MDN docs.
And I think, there's a lot of power there in embracing what the browser gives to you just by nature. It's a big platform and has a lot to offer. There are certainly shortcomings that hopefully will overcome, but all the way back in PHP days, we solve so many of these problems. And then, we just solve them again in JavaScript. And I love [crosstalk 00:32:48] just getting rid of the JavaScript solutions in an elegant way so that I can both have my cake and eat it too.

Ryan Florence (33:00):
Yeah. And, it's a lot about resilience. Sometimes, JavaScript doesn't load. Sometimes, people have a really poor connection. And so, you actually do want JavaScript so that when you're navigating between pages, you're just making a tiny fetch for the next data, rather than ... Even hitting the cache for 30 resources takes time. And then, the browser has to re-parse all that stuff too. So, there are benefits to having the JavaScript in there, benefits to not having it. And so, we've built it in a way where it's like, whichever one you want, or if JavaScript fails to load, the Apple still work, or you got to support a11y. Well, we use script type module, so it won't even load those. So, if you build your core feature set on just declarative forms, then you can support a11y, a subset of your features anyway. And, Remix would just kind of cool.
So, I value the fundamentals a lot, but I don't ever want to give the impression that ... It's a thing that a lot of people say, "I can't believe people don't know HTML," and "You need to learn the fundamentals before you use something like React." And, you can tell by my voice. I don't like that kind of language. I'm someone. I'm very pragmatic. And I learned web development, serious web development through MooTools and Ruby on Rails. I did not learn JavaScript before I learned MooTools. I learned MooTools, but MooTools stayed at the right level of JavaScript where it just kind of extended how JavaScript worked, but gave me enough to be productive without knowing a whole lot that I accidentally learned JavaScript. And, Rails was the same way with Ruby.
I was just copying and pasting examples and just running through, I'm just writing Rails. And then one day, I woke up and realized, "Oh, I know Ruby." I didn't realize. I'd never actually sat down and done a learn Ruby tutorial. I just kind of, by using the framework and copy pasting and just looking at examples. I had no idea I was learning Ruby. I thought this was all just Rails, and same with MooTools. I didn't know I was learning JavaScript. I thought I was learning MooTools and I accidentally learned JavaScript. So, that's a big thing for us with Remix as well. We want APIs that are really helpful and make things really easy. And I think, we've done a good job with that, but we're careful not to go too far away from fundamental, too far away from how the browser works or the real APIs.
And you'll see if you use Remix that a lot of the code, like you just said, you're on MDN a lot, looking at how URL search parameters work, or how request and response objects that you get back from fetch. What are those? Because that's our primitive for HTTP is the web request model that we got with fetch. We want to keep it close enough to the platform that when you learn Remix, you accidentally learn how to be a better web developer. Stuff you might think is something specific to Remix like a cache control header or the response object or request object. They're actually not Remix. They're just the web. They're just HTTP. And so, that's a goal of ours. Get good at Remix, accidentally get good at web development, generally.

Kent C. Dodds (36:32):
I love that. And, we're overtime so we can't go on, but there are so many things I'd love to go on about, like talking specifically about some of the trade-offs that you made with Remix and the way that you built it. But we'll have to talk about that another time. So, for our homework for today, Ryan just wants you to get better at building websites and in particular with the foundations of the web. And so, the homework for you is to spend an hour or two reading the MDN docs on HTTP. That's the Mozilla developer network, if you've unfamiliar with that. And, we'll have a link to that in the notes. Ryan, it's been awesome chatting with you. What's the best place for people to keep up with what you're up to?

Ryan Florence (37:20):
Just Twitter, Ryan Florence.

Kent C. Dodds (37:23):
Sweet. And, we'll have a link to that too. All right. Thanks, Ryan. This has been awesome. And thanks everybody for listening. We'll see you later.

Ryan Florence (37:29):
Adios.