Kent C. Dodds (00:00):
Hello, friends, this is your friend, Kent C. Dodds. And I'm excited to be joined by my friend, Michael Jackson. Say hi, Michael.

Michael Jackson (00:06):
Hey, Kent. Thank you so much for having me on the podcast. Super excited to be here.

Kent C. Dodds (00:10):
Oh, I'm glad that you're excited. I'm disappointed that you said, "Hey, Kent." I asked you to say, "Hi, Michael." But that's okay.

Michael Jackson (00:16):
Oh, yeah, right, sorry.

Kent C. Dodds (00:18):
Gotcha. Start over.

Michael Jackson (00:21):
Rewind, rewind.

Kent C. Dodds (00:23):
So, Michael and I have been friends for, boy, I think the first time we met in person was probably at a conference, I think React Rally. Is that right?

Michael Jackson (00:34):
Yeah, it must have been...

Kent C. Dodds (00:36):
You know what, maybe it was React Conf.

Michael Jackson (00:39):
I remember that place. We were in a hotel. It was React Conf. It was React Conf 2016. Because I remember we were in the Marriott Hotel in San Francisco. The first year in 2015, they had it at the Facebook Campus. But in 2016, they did it at this hotel downtown San Francisco. And I remember meeting you there.

Kent C. Dodds (01:04):
Yeah, yeah.

Michael Jackson (01:05):
Remember that?

Kent C. Dodds (01:05):
So, early days. Yes, I do. I do remember that. That was actually when I was doing JavaScript Air. And I did a live show at React Conf. That was fun.

Michael Jackson (01:14):
And I was like, "Kent," I was like, "you need to tell people that you like React." And I remember you were like, "Okay, I like React." I was like, "Say it louder, Kent."

Kent C. Dodds (01:30):
Yeah. And I was like, "l'll tweet it." And I tweeted it. So many people find that tweet.

Michael Jackson (01:34):
Oh, for sure.

Kent C. Dodds (01:36):
Yeah, it was fun. So, yeah, it's been a long time. And it's just been a pleasure to get to know you over the years.

Michael Jackson (01:42):
Thanks, man. Same.

Kent C. Dodds (01:44):
And run into you at conferences and stuff. Looking forward to doing that again as COVID runs away.

Michael Jackson (01:50):
Oh, my gosh, I'm so looking forward to getting back to in-person stuff. It'll be so nice.

Kent C. Dodds (01:55):
Yeah, for real. But I actually love if you could give a little intro to yourself. You can be as personal or professional as you want and take as much time as you like. We just want to get to know you a bit.

Michael Jackson (02:06):
Yeah, for sure. So, my name is Michael. You can find me online. I tried to snag the MJackson Twitter handle or handle anywhere I can. So, that's me on Twitter. And I'm MJackson on GitHub. And those are probably the only two places you really care about. But I've been writing JavaScript for a long time now. I think I wrote my first line of code back in like 2007 was when I was getting started with it.

Kent C. Dodds (02:38):
I graduated from high school that year.

Michael Jackson (02:41):
Nice, nice. And so, yeah, I was in college at the time working and just trying to figure out what I wanted to do. And so, I took a programming class and really enjoyed it. And so, that's how I kind of got into programming. I was at BYU at the time, actually.
Yeah, and all the best paid jobs on campus were programmer jobs. So, the people who were doing like, there were lots of different jobs. You could be like a janitor, do landscaping or be like a TA or something. But the programmers got paid 12 bucks an hour. So, yeah, exactly.
So, I was like, I'll do that. So, I applied to three different programming jobs. But I didn't actually know how to program and I got one of them. And so, I was like, "All right, I'll go and figure this out." So, that was kind of my origin story there, learning how to program.

Kent C. Dodds (03:36):
Well, that's awesome.

Michael Jackson (03:39):
Yeah. So, a couple of other things about me. I'm married with four kids. I have two boys, two girls. The oldest is 14 and the youngest is six. So, we have a full house and I live in Southern California, kind of close to San Diego. So, if you're down here, hit me up. I would love to go and grab a burger or something sometime. But yeah, that's me.
And okay, so a couple of things I built probably is probably-

Kent C. Dodds (04:07):
Oh, yeah.

Michael Jackson (04:07):
I should say that as well. So, I built React Router is one of the biggest things I've built together with my business partner, Ryan Florence. We've been working on that thing almost since React came out since about 2014, late 2014.

Kent C. Dodds (04:25):
Wow.

Michael Jackson (04:26):
Yeah, it's kind of crazy to think we're still working on it. But actually I've never been more excited about it. Like we've got some killer stuff coming in v6 that I think people are really going to like it. It's going to really make it a lot easier to build really cool stuff in your apps. We're going to have a story for how you do data in React Router, both reads and mutations.
We're also going to have a story for doing everything relative. And the beta is out now. It's been out for a while. It's stalled a little bit because COVID kind of took a chunk, a huge chunk out of our business. So, we had to focus on actual revenue-generating opportunities last year and we weren't able to dedicate as much time to open source. But it's been out there and it's been stable. And a lot of people are actually using it in production already, the v6 beta.

Kent C. Dodds (05:26):
I am using it for [crosstalk 00:05:29].

Michael Jackson (05:30):
I mean, we're building remix on it. So, we're building our current software on it. So, yeah, it's a cool project. So, that's one thing that I built. And then, I also built this thing called unpkg, which Kent has also blogged about. Thank you Kent.

Kent C. Dodds (05:47):
Yeah, yeah.

Michael Jackson (05:48):
But unpkg is, it was just kind of like a little burst of inspiration where I was like, there are a bunch of files on npm. What if all of those files had a URL? And that was it. That was the whole idea. That was the whole thing. And so, that's unpkg. And unpkg is CDN basically for all the files on npm. And that thing does quite a bit of traffic now.

Kent C. Dodds (06:15):
Yeah, I started using that back when I was still doing AngularJS and using it for my Angular formerly demos and stuff. That was transformative for me. I loved that.

Michael Jackson (06:26):
Nice. Yeah, I think you were one of the first users. John Lindquist I think was using it as well. I remember actually, he took it down one day. I was like, "John, what are you doing?" He's like, "Oh, sorry." That was the day where I was like, "Well, it should probably have a real CDN in front of it. So, I wouldn't put Cloudflare in front of it so that somebody couldn't take down my origin server."
And Cloudflare has been amazing to work with. They've given me a free enterprise account to work with. And I mean, last month, we did a petabyte of data.

Kent C. Dodds (06:58):
Just outrageous, of JavaScript files?

Michael Jackson (07:01):
It's crazy. Well, I think a lot of people, too, are using it for like images and icons, CSS. I mean, people are publishing all kinds of stuff to npm these days. So, yeah, it's grown quite a bit. And it's pretty cool. It's useful. I use it, I still use it. I think probably the most useful thing for me is when I want to know what is in the package.

Kent C. Dodds (07:21):
Yes.

Michael Jackson (07:22):
And I go and I just add a slash to the URL and then I can go in C. Everything that's in a certain version of a package. But yeah, so that's me. Those are some of the things that I built. And then obviously, my latest project, not obviously necessarily, but my latest project is called Remix, which I'm also working on with Ryan. And Kent has been ... Thank you, Kent. You've been awesome, like, tweeting about it and just telling people about it.
But yeah, it's basically, it's like React Router, plus, if you can imagine that. It's like React Router, like all the things that we always wanted to do with React Router. Because we know that it's such a cool little piece of software. It's this cool little core and you can do such amazing things with it. And we want to help you do even more with it. So, how to use server under a React Router app and how do you fetch data with it and take care of mutations and load your styles and do transitions and all that sorts of stuff. So, that's what Remix is, is it's like React Router taken to the next level.

Kent C. Dodds (08:35):
Yeah. And it really is. That's awesome. One thing about your origin story that I was curious about, what year did you graduate from BYU?

Michael Jackson (08:44):
2008.

Kent C. Dodds (08:46):
Okay, yeah. Sweet. So, like I said, I graduated from high school in 2007. But I went to my first semester at BYU in the fall of 2007. So, we overlapped by a semester.

Michael Jackson (08:58):
No way.

Kent C. Dodds (08:58):
Then I went on [crosstalk 00:08:59]. But yeah, we were-

Michael Jackson (09:01):
We were there for the same year. Yeah. My last year was your first year there, crazy.

Kent C. Dodds (09:05):
It's kind of fun. Good times.

Michael Jackson (09:09):
Where were you? What were you studying?

Kent C. Dodds (09:11):
I was-

Michael Jackson (09:12):
Well, that year, you were just doing generals.

Kent C. Dodds (09:14):
Yeah, that year it was mostly doing generals. I did CS 142 and 120 or something like that.

Michael Jackson (09:20):
Yeah.

Kent C. Dodds (09:21):
[crosstalk 00:09:21] computer programming.

Michael Jackson (09:22):
142, yeah.

Kent C. Dodds (09:23):
Yeah.

Michael Jackson (09:23):
That was a tough class.

Kent C. Dodds (09:26):
Yeah, yeah.

Michael Jackson (09:26):
For 100 level class, that's a tough class.

Kent C. Dodds (09:29):
It was a little tricky. And then, the computer systems was harder. I can't remember what number that was. But that was an engineering school. And when we started with programming and zeros and ones. Yeah.

Michael Jackson (09:44):
Is that your degree, is computer engineering?

Kent C. Dodds (09:47):
No, no. So, I was going for electrical engineering and then when I went back for my mission, it was like, I'm not very good at math and I don't know.

Michael Jackson (09:55):
Everything changes. Yeah, yeah.

Kent C. Dodds (09:57):
So, I bounced around, eventually graduated information systems, but yeah, good times.

Michael Jackson (10:02):
Oh, I graduated in information systems.

Kent C. Dodds (10:05):
Oh, nice, nice. Yeah. [crosstalk 00:10:07] earlier classes.

Michael Jackson (10:07):
Yeah, we probably had some of the same instructors and stuff.

Kent C. Dodds (10:11):
Oh, my goodness. That's awesome.

Michael Jackson (10:12):
Yeah, I was there with Lindstrom, Albrecht and...

Kent C. Dodds (10:17):
No way.

Michael Jackson (10:17):
I can't remember some of those other people. Yeah.

Kent C. Dodds (10:19):
We haven't made this connection already.

Michael Jackson (10:21):
Same program, same school. Like what, like three years apart? You probably graduated like 2010, 2011.

Kent C. Dodds (10:28):
2014, actually.

Michael Jackson (10:28):
Oh, '14. Okay.

Kent C. Dodds (10:29):
That's aways after you. But, yeah, did you get the master's?

Michael Jackson (10:34):
You know, they were like, if you stay one more year, you can get your master's and I was like, "I can't do any more school. I'm sorry. I need to get out of here." I probably should have. But I was so excited.

Kent C. Dodds (10:45):
My master degree hasn't done me a whole lot of good.

Michael Jackson (10:48):
So, you can make a little name tag and call yourself Master Dodds.

Kent C. Dodds (10:54):
That's true, which I think is better than doctor, so.

Michael Jackson (10:57):
Yeah, it's better than bachelor.

Kent C. Dodds (10:59):
Yeah.

Michael Jackson (11:00):
Bachelor Jackson, doesn't sound that great.

Kent C. Dodds (11:03):
Well, yeah. Anyway, so the thing that you're working on now, and I already talked with Ryan, so anybody who's listening to this and hasn't already listened to Ryan's side of this, make sure you give that a listen. But in this chat with you, I wanted to dive deep into what Remix is and what makes it special. Beyond just that, it's based on the fundamentals and foundations of the web and that sort of thing.
So, just to kind of frame this conversation, I just today published a blog post titled, Don't Solve Problems, Eliminate Them. And I gave a couple of examples of different things like in real life of companies that eliminate problems and people who create problems for themselves at different things like that. And Remix was an example of a software that eliminates a bunch of problems.
But I also acknowledge that when you eliminate problems, you typically are taking just a different approach and you accept tradeoffs. And so, you're creating new problems. And hopefully, solving those problems is cheaper, easier and better than solving the problems that you had before that you had eliminated. So, anyway, yeah, I just love to talk with you about some of the problems that you feel like Remix eliminates and what tradeoffs you're making in the process. So, yeah, with all that said, what do you think makes Remix so special? What's special about Remix?

Michael Jackson (12:31):
Absolutely. I, first of all, just kind of want to speak a little bit to the principle that you're talking about, which is that certain solutions or certain things, like you could even have an entire system or an entire library that when you take a different approach, you just don't really have the need for that system anymore or that library, whatever.
I think one of the most amazing examples that I ever saw this in my programming career was when I was at Twitter in ... I was a software developer at Twitter in 2011, 2012. And it was just around the same time that Instagram was really taking off. Instagram started a little earlier than that, but it was about the time they were really taking off.
And I knew some of the engineers that were at Instagram at the time very early on. And I had actually interviewed there and they were really, really smart people. And we had a lot of smart people at Twitter, too. But we took two very different approaches to solving this fundamental problem. And the problem was generating IDs.
And you think about it like it's not a problem that you typically have. If you need to generate IDs, maybe you've got a MySQL database, you have an auto-incrementing column, that's the ID column. And as you insert new records, MySQL generates an ID for you. And then when you get them back out, now you've got your ID, done, right?

Kent C. Dodds (14:03):
Yeah.

Michael Jackson (14:03):
Not a problem for most businesses. But at the scale that both of these companies were at Twitter and Instagram, it was a real problem to generate unique IDs as quickly as they needed them because they need it on the order of millions every second, they needed these IDs, because just from the sheer volume of traffic that they were doing.

Kent C. Dodds (14:25):
And we're not just talking like a single tweet or a single image, but so many aspects of the data that's in those things need to have a unique ID.

Michael Jackson (14:35):
Exactly, yeah, your users, your tweets, your posts, your videos, your likes, whatever, things, everything's got an ID attached to it. And I remember reading a blog post and it's still up on the Instagram engineering blog, where they talk about how they solve this problem for Instagram. They basically took their Postgres database, they sharded it into 256 shards. And then they ran a little script on each of them that was written in this, it's this procedural language that goes into the Postgres database. It's called PGPLQL or something. It's got this weird name, I forget what it's called.
But anyway, they wrote this tiny little script and it basically on insert into that database, it would take the current timestamp, and the shard ID, and then I think an integer that they could generate a thousand of them per second. So, like a counter per second.
So, they actually have the ability across 256 shards to generate hundreds of thousands, or maybe even millions, I forget the exact numbers, of IDs per second. And they just use this thing that was built into the database because they had a very small team. And so I was working at Twitter at the time. And I contrasted that with what we were doing at that time. And I don't know if they still do it.
But Twitter actually had a completely separate service, a triple redundant service for generating IDs. And it's basically just a server that sits there. And you can ask it for IDs. And obviously, if it ever goes down, the whole system is hosed. So, they had another server that automatically take over in case that one failed. And then they had another one that would automatically take over in case the first two failed because-

Kent C. Dodds (16:30):
Double redundancy, yeah.

Michael Jackson (16:31):
Well, because if you have something like that, and literally, the whole system relies on it. You can't tweet, you can't sign up, you can't do anything, unless you can get an ID. So, you can create that record and put it in your database. And so, they had to back this thing up and it was called Snowflake. And so, that was one solution to the ID generation problem. And you probably had a team that has to manage these servers and look after them over this time.
And this other one, this other solution from Instagram just seems so much more, I don't know, just so much more elegant to me, to embed this little script in the database, shard it across 256 nodes. And now we've got ... We don't even have the need for that ID generation system. That whole system is just superfluous to us because we took a different approach. And it's been something that I've been fascinated with my entire career is this idea about how, when you hit on the right abstraction, when you get the right approach, other things just kind of melt away.
And I think you see this too in your code. If you ever get to the point where you get to delete a bunch of code for some reason, it's an amazing feeling, because you found some other kind of approach. And lots of times, it happens when you find something better, you find a better abstraction, and you get to delete a bunch of code.
So, one of the things that I really love about what we're doing with Remix is we're just building it on web standards. So, I feel like there was a lot of stuff that we have built in the current generation of web frameworks, abstractions and things that we built, data layers and client-side caches and things that we've built, where the browser actually has a really good primitive already for that solution.
I'll give you one example. So, one example is a data cache, a client-side data cache. We actually thought, in the very first prototypes of Remix, we thought, well, we don't want to make unnecessary fetches to the server. So, what we're going to do is we're going to have a client-side data cache, and it'll just be this little hash, and it'll just live there in memory and it will key it by location.
So, as you're navigating around the locations, if you've used React Router, they have this little key property on them. And it's just a unique ID that just lets you know where you are. And we'll just keep it by that. And then if you hit the back button or the forward button, we won't have to go and refetch from the server the data because we already have it here in our cache.
And you've seen this play out on a regular old server rendered site a hundred times. If you're browsing around and then you click the back button, the browser is able to restore a lot of things. It'll restore the page and the data and in lots of cases, it will even restore the scroll position if you scrolled halfway down the page when you navigated out. So, it's able to give you this really, really quick back button experience.
And building the client-side router like React Router, we wanted to give you that exact same experience. When you hit the back button, it's just like if you're doing a client-side navigation, it's supposed to work just like a server side navigation. You're going to go back to the last page. You're going to have the exact same data there, the exact same scroll position.
So, anyway, this client-side data cache, this was part of our strategy for making that happen. We're going to cache all the data client side. And we haven't figured out how to purge the stale data. Because now anytime you have a cache, now, you've got to figure out, well, how do we expand. You purge stuff out of the cache.
So, anyway, so we were taking this approach. And then at one point, it kind of hit us. We're like, wait. So, when you make a request to a server from a browser, in the HTTP response, you can put caching headers. And this is essentially how you tell the browser, "Hey, you can hang on to this response for X amount of time." So, you can hang on to this response for a minute or five minutes or an hour a day or forever.
And this is something that we typically rely on quite heavily for things like static assets. So, when you go and deploy, you generate hash CSS and JS files, and then you tell the server, just send the cache headers that will cache this forever because the next time I deploy, the hash is going to change. And so, I don't want them to ever have to redownload this file. And we figured like, so we can use that exact same thing for our client-side data cache.
We don't need to keep a hash in memory. We can just say, look, in your data loader, you send back some caching headers. The browser is going to see that and if we ever make a fetch to that URL ever again, the browser is going to not make the fetch to your server, because we're going to say, "Oh, go and fetch the data." And it's going to say, "Well, I already got it actually, it's still fresh since the last time I fetched it. So, I'll just use that."
So, it's not like the browser gives you like a programmatic API into this cache. You can't say, "Hey, go and look up in the cache and see if you have the key, "or whatever. Well, you can actually do some things in service workers. You have a cache API there. But in the normal browser, you don't. Nevertheless, you do, you are able to take advantage of this catch.

Kent C. Dodds (22:11):
So, you don't need an API.

Michael Jackson (22:13):
Yeah, exactly, exactly. You don't need an API. You just make the fetch. And if the browser has it cached, you'll get it back. And so, this is an example of one thing that for us and Remix and for ourselves, an entire thing that we were able to avoid by just using the right abstraction. So, how does that play out for Remix users? Right, somebody who's using a Remix app, or sorry, sorry, someone who's building a Remix app is using Remix.
If they're just loading data from the server, they don't actually need to have their own client-side data cache, which lets them avoid a bunch of problems, like, how do you control the size of the cache, how big it gets? How do you know when to purge stuff out of the cache? This is definitely a problem that you've had to solve if you at any point decided you wanted to cache your data client side.
It's something that we rely on in Remix and it just comes out of the box. And by the way, because of the nested nature of React Router, we'll actually only fetch the data for the routes that have changed on the page. So, something like GraphQL, where you said, "Okay, I've got this GraphQL query. I want to avoid the overfetching. How do you figure out how to run just the query for just the pieces of the page that have changed." It's all built into React Router. We've got this concept of routes and your data is tied to your routes.
So, I mean, there are multiple levels to this overfetching problem, but that's at least one level where I think we're able to solve it by just using something that's built into the browser and not inventing our own thing.

Kent C. Dodds (24:05):
Absolutely. Well, and whether you use GraphQL or not, you can use GraphQL with Remix, but because if you write your data fetching stuff inside of a loader that runs server side, and so you don't need to worry about overfetching data. You just filter it out in the loader, which is happening server side, and then all that you send back to the client is 100% what the user needs. And so, the overfetching problem doesn't exist in Remix. You've eliminated that problem altogether.

Michael Jackson (24:36):
Yeah, 100%, yeah. So, speaking specifically about GraphQL, you absolutely can use GraphQL in your Remix app. If you've ever written a GraphQL server, you've probably got your, I think they call them resolvers. You've got your resolvers that when the query comes in, if you need some piece of data, those are the things that are responsible for going out to your real database, your Postgres or MySQL, or whatever, and actually fetching the data so that you can return it in the GraphQL response.
We've actually got a similar mechanism in Remix, called a loader. And that's where you can do your resolving. So, you can go and do your fetch. Go and query MySQL. Go into even just a HTTP fetch to some other API server. Do your sorting. Do your data filtering. And then just return the minimum amount of data that the view needs.
So, you might think, well, in order to solve this problem of over fetching, we actually need to go and build a GraphQL server, maybe you don't. Maybe all you needed was a framework that knew how to only, first of all, only call the loader for the piece of the page that has changed. And then second of all in that loader, be able to cache the response and stuff, so that when the browser goes to ask for it, again, doesn't have to make the network round trip.
So, I feel like by hitting on the right abstraction, I feel like a lot of the pieces that you might have thought you needed, maybe you don't need them anymore. And instead, you can just sort of use things that you already have that are built into the browser that were ... It wasn't impossible to use them before. But it was definitely a little more difficult without some of the tools that we're providing as part of Remix.

Kent C. Dodds (26:34):
Oh, yeah, absolutely. It's interesting, like the problems that these other tools solve, like Apollo or for the GraphQL for the client-side and caching, or maybe Gatsby for static site generation, so you just have to build it once and then you never worry about building it again for it over and over again.
And these problems exist. It's not like they just solved problems or that didn't happen. But the issue is that their solution creates a whole host of other new problems, which they are addressing, they're working on those things and making those things better. But if we could take a step back and say, "What if I didn't have that problem, is it possible for me to not have that problem?"

Michael Jackson (27:20):
Yeah. And it's like that. It's like that ID generation problem that I was talking about. Yeah, what if we don't have the problem, then we don't have to create an abstraction to try and fix the thing that's not broken.

Kent C. Dodds (27:32):
Exactly. And because the browser has so many things already built in, if you can leverage those things, you have to worry about those things, either way. If you make your own JavaScript based solution or you don't. Either way, you have this built in solution. So, you may as well find a way to use it and Remix has.
Another thing that I wanted to ask you about was CSS because I've been through all of it. I started with regular CSS. I did less. I did SaaS. I did stylists. And then I got into CSS modules. And then I got into CSS and JS. I built a CSS and JS library. And I've done it all, like the CSS prop and like styled components. All of the things, I've done them all. And I've never been so excited about CSS since jumping into Remix.

Michael Jackson (28:21):
It's cool, right? Ask yourself, if you're listening to this podcast right now, and I know it's a little weird to talk to the listeners, because I'm supposed to be talking to you. But if you're listening right now, just think, how do you only get the CSS on the page that is necessary for that page? That's a hard problem solve. And we're not punting on the problem at all. But we are taking a different approach by using nested routes and React Router.
So, just like the data loaders, where we only call the data loaders that you need for a given page, or as you're transitioning client side between pages only call the data loaders for the routes that have changed. We do the exact same thing for your CSS. So, the CSS for the components that are on the page is the only CSS that is loaded when they're looking at that page. And then if they change one of the nested routes, we only have to load one new CSS file just for that route.
So, it's, again, not something that was impossible to do before. But it's something that in Remix, it just falls out of the framework. So, naturally to do it like this, that I am starting to look at a lot of the things that we have been using over the last couple years and wondering, is that necessary? Do I need a build tool that's going to obfuscate all of my CSS class names if I'm not even going to have these two CSS files on the page at the same time?

Kent C. Dodds (29:55):
Yeah. The thing that really blew my mind and maybe for some people, this will blow their mind, too, and it's so simple. But what Remix does is not only does it get the CSS onto the page for a given route. But when you leave that route, the CSS is unloaded off of the page. The link tag goes away. And JavaScript, if you do that, the JavaScript has already run. It's hanging out in memory. You can remove the script tag, nothing changes.
But with CSS, you remove the link tag, and that CSS is gone. And the browser repaints. And it says, "Oh, that CSS doesn't play anymore." And so, because of this, and I've never seen anybody do this before. So, Remix [crosstalk 00:30:37].

Michael Jackson (30:37):
It's cool, right? It's so cool, right?

Kent C. Dodds (30:38):
Yeah.

Michael Jackson (30:39):
And we can even do things like when you're doing a client-side navigation, we can actually wait for that style sheet to load, which is again, another thing that you're going to have to think about unless you want a flash of unstyled content, something that you're going to have to think about, but not ... So, it's built into the framework in Remix so you don't have to think about it. But yeah, it's just another one of those things.
And again, it's not like you can totally do that yourself. But we're just building it on web standards and making it easy for you to build your site on web standards. And you're going to learn a lot about web standards in the process. That's one thing that I'm very bullish about, that I'm very excited about with Remix is, a lot of the discussions and things that we're having in the discord channel, we're all learning about this stuff together.
We had a conversation just the other day about module preload and script defer and how that all works. And we're determined to take all of the best that the web has to give us and make it really, really super easy for you to take advantage of. And you're going to learn a lot in the process. So, that's probably one of the things I'm most excited about is just myself and for everybody who uses Remix, I just want to cultivate a really nice community where we're all just learning together and building really cool stuff together in the process.

Kent C. Dodds (31:58):
Yeah. And basing things on web standards also, not only does it mean that I'm spending tons of time on MDN instead of Remix docks, which is a really nice ... That means that my skills are transferable. I'm learning this stuff and this is actually one of the things I loved about React was, I was coming from AngularJS and I spent so much time digging through AngularJS specific stuff. And when I moved over to React, I couldn't carry very much of that with me.
But with React, the better I get it at JavaScript, the better I get at React and vice versa. And I feel like Remix makes me a better website builder, by accident. I'm building websites with Remix. And then, if I'm going to do something outside of Remix, I'm better at doing that just because I learned the web platform with Remix.

Michael Jackson (32:48):
Yeah, yeah. You're learning about things like HTTP headers. You're learning about HTML. You're learning about forms and data mutations and post and put and get and link tags and loading stylesheets and things like that. We're not teaching you, here's the Remix templating language. That's garbage. That's not a web standard.

Kent C. Dodds (33:13):
To be clear, Michael, one thing that you didn't say earlier in your intro was that you created mustache. So, when you talk about templating languages, you're like the grandfather of [crosstalk 00:33:26].

Michael Jackson (33:26):
Guilty, guilty, 100%. So, I was actually working at Twitter at the time. And all of Twitter was done using mustache. But it was just slow. And so, they were like, "How can we make this faster?" And it didn't occur to me to say, "Just use JavaScript." That's what the smart people at Facebook were doing at the time. I was like, "Let's rewrite mustache." So, I went into the Mustache JS project and got commit rights from [Jan 00:33:52], who's awesome guy. Thank you, Jan.
But anyway, and I put like a parser and a tokenizer and everything and I rewrote Mustache JS. And I was like, "Okay, it's so much faster now. Okay, it's so much faster for our product." And then people would come to me and they would say something like, "Those little curly braces that you have, can I like add two numbers inside there? If I have a string, can I call 2.2 uppercase on that string inside the curly braces?" And if you're familiar with mustache, you'll be familiar with the curly braces. That's what the mustaches were.
And I remember thinking like, "No, you can't. You can't do any of that stuff. This isn't real JavaScript. This is just some silly templating language." And I am now literally writing my own language. I have conditionals and I have four loops. And then, we have all this documentation about it and stuff. And then, when I found the React docs, I was like, "These don't say anything about their special templating language, their special syntax for a for loop or for an if statement." There is nothing about their own secret templating language in these docs. It is literally just, if you need to loop over something, use a map. Or if you need a conditional, use a ternary or something like that.
And so, it's just JavaScript. And I think you really nailed it. That's the spirit of React is just use JavaScript. And I would say, the spirit of Remix is just use the web. And in the process of using Remix, you are going to learn more about the web and you're going to become more proficient that these things that in your next job and your next, whatever, they're totally transferable. You're going to know a lot more about HTTP and HTML, and some of the things that the browser gives you. We're not trying to teach you Remix specific stuff.

Kent C. Dodds (35:47):
Yeah. Well, even then though, I don't know why I'd want to transfer my skills to anything else because I enjoy Remix too much.

Michael Jackson (35:55):
Awesome. Yeah, I mean, it's fun. I'm having a blast with it.

Kent C. Dodds (35:59):
It's been really productive. It's a very productive framework.

Michael Jackson (36:04):
Cool, cool. That's the spirit that we're trying to capture. I've been doing this for a while. And I'll never forget one of my favorite frameworks for back in the day was a framework called Code Igniter. And it was literally just, that's how you felt when you use it. And I think all of us who are in development for a while, hopefully you had that experience when you first got in and before things got really complicated, you used something that really captivated your attention and was very expressive. You were able to take your ideas and make something very quickly. Hopefully, you got that chance.
I know for a lot of us, it was PHP. For other people, it was C sharp. For some people, it was Visual Basic. And that is the high that I feel like I've been chasing ever since I got into programming because I was so highly productive with that. And that's the thing that I think about when I'm working on Remix is how can I make this feel incredibly lightweight, incredibly distraction free, and just highly productive? And that's really what we're going for. So, I'm glad you feel that way. That's awesome.

Kent C. Dodds (37:15):
Yeah.

Michael Jackson (37:15):
It really is.

Kent C. Dodds (37:16):
That's such a good place to end. But I don't want to, so I'm going to say one ... I went to one other thing, and that is I just want to give people an idea of what the Remix API really is. Because one of the things that really attracts me to Remix is how little of an API there really is. There's not really a whole lot of API there. And I think the biggest thing that people interact with the most with Remix is the module API, so each individual route.
In some ways, it's similar to Next, where you have your routes are file based. And of course, they can be dynamic with the Remix config as well. But can you talk a little bit about the route module API that people are going to be interacting with most with Remix?

Michael Jackson (38:04):
Yeah, 100%. So, we have these things called route modules. If you've built a React Router app, typically a route is associated with a React component. When the URL looks like this, go and render this component. That's basic, basic React Router stuff. And what we've done in Remix is, as I said, we've kind of taken that to the next level. So, now instead of just a component that's associated with your route, and a lot of this stuff is going to make it back into React Router, too. It's not all going to stay here. Remix is absolutely going to make React Router a better product.
But what you've got now is you've got these other things, too, that you can associate with a route. So, we've talked about associating data with a route or associating styles with a route. We've also got the ability to associate HTTP headers with a route. So, in the HTTP request, you're going to get back some headers, both in the document request and then also in the data request, you're going to get back some headers. You can associate some arbitrary data with a route if you want to construct like a breadcrumb or something like that from the routes that are currently on the page.
So, the way that we've designed this API was we're basically just using the ES module API. So, in a route file, everything that is part of that route is a named export from that file, while the component is the default export, but everything else is a named export from that file. And the cool thing that we can do with that is it allows us to just kind of like dice up that file however we need to.
So, this is one of the cool parts of Remix that we haven't even talked about yet. But we're really doing some cool innovation in the space of deployment as well. So, you can actually deploy Remix to a number of providers already. They're all based on node up to this point, but I'm working feverishly on a version that will run on Cloudflare workers.
But the idea is take this route module and run it on a node server. Okay, now take the exact same code and go and run it in the browser when this route is rendered, when that route is [crosstalk 00:40:23] client. Yeah, exactly when it's hydrated. So, you can go do client-side rendering and routing if you want to or you could just have a purely server rendered site or you can have some kind of hybrid.
And my goal, actually, is to make it so that ... I don't know if we've actually talked about this, but my goal is, so right now, you've got an entry.client.js and an entry.server.js. And my goal is, if you remove one of those files, we'll automatically know what to do.
So, if all you have is an e entry.client.js, we'll assume, okay, you're just creating like a create React app client-side thing and it's purely client-side app. Okay, you don't have that? All you have is an entry.server.js? Okay, well, then it's purely a server rendered app. Oh, you have both of them? Well, then we're actually going to do both of them and we're actually going to do the hydrate or something. But it's just future sort of thinking.

Kent C. Dodds (41:25):
Fun stuff.

Michael Jackson (41:25):
But anyway, yeah, the route API, getting back to that, the route API is built so that it can run in either of those places and we can just sort of grab the exports that we need to run in any given environment and say, "Okay, we'll run this one here and we'll run those over there." And so, that's kind of how it's shaken out. And it actually works really, really well with JavaScript build tools that understand DS modules, which of course they all do now, to we have these flexible objects, where you're just describing, here's all the stuff that's associated with this route.

Kent C. Dodds (42:00):
Yeah, yeah. Well, and being able to say, "Here are the link tags that I want in there."

Michael Jackson (42:05):
Yeah.

Kent C. Dodds (42:06):
It makes it easy for ... Like the meta tags, I can update my title. I don't need to have React helmet in there or anything. And you mentioned entry.server and entry.client, I'm the one responsible for hydrating. I'm the one who calls ReactDOM to hydrate. I'm the one who calls render to string. And so, it just gives me an enormous amount of flexibility. And you don't have to create some API or convention for me to be able to override those things. I'm the one rendering the HTML tag, all the way up to the top.
And that amount of flexibility just makes me really happy about the lack of API that Remix does have. That's just less things for me to learn. I don't need to ask you questions about how do I do these things because, well, it's staring at me in the face.

Michael Jackson (42:53):
Yeah. Somebody asked me the other day, they're like, "Do you support streaming?" And I'm like, there's nothing for us to do to support streaming because you own your entry point. You are literally the one who calls ReactDOM.render to string. So, if you want, call render to node stream, and now you support streaming. We didn't have to support that at all. We just gave you access to your entry point. And now, you're streaming your response instead of buffering it, so.

Kent C. Dodds (43:26):
Yeah, yeah. It's amazing. I just think that's awesome.

Michael Jackson (43:28):
Cool.

Kent C. Dodds (43:28):
So, we're well over time.

Michael Jackson (43:31):
Yeah.

Kent C. Dodds (43:31):
But I did want to talk about an elephant in the room that some people are concerned about. Every time I talk about Remix, somebody makes a comment like this, about the funding aspect. And so, if you could take a minute or two to talk about how Remix is funded, and yeah.

Michael Jackson (43:49):
100%, yeah, I'd love to talk about it. So, if you're paying attention right now in open source software, we do have a bit of a problem. And it's been a problem for years now. There's so many tools that have struggled to get the kind of funding that they needed.
Some have turned to foundations like Apache or the JS Foundation to get the funding that they need. Some have turned to academic institutions or benevolent corporations who have been willing to grant them the funding that they need or maybe they'll hire the people who work on the open source. And now, the open source has the funding that it needs. Maybe you're just straight up relying on donations having an open collect or something.
It's a big problem right now. And so, I think, and it's been a problem for a while. So, the approach that we're taking to fund the open source work that we do and make no mistake, if you're listening to this, a lot of the work that we're doing is open source work and it is to make a better React Router for everybody. But we do need a way to figure out how to fund it and to make it sustainable. Otherwise, we just like, it just [crosstalk 00:45:07]. It'll stagnate and I can't work on it anymore, right?

Kent C. Dodds (43:49):
Yeah.

Michael Jackson (45:11):
And so, how do we do that? So, for the last couple of years, the answer for Ryan and I was, "Well, we'll run a training business. We'll go train people on React, and then we can work on the open source, too." And, like I said, COVID kind of took a chunk out of the training business and made that a harder way to earn a living for us, at least with in-person trainings.
And there's also this thing that we know that React Router is so much more capable than it currently is. And so, we really want to take it to the next level. And so, that's where Remix comes in. The clearest path towards funding anything is to create something of value and to ask people to pay for it. And if it works and people show up and they pay for it, then your incentives are aligned.

Kent C. Dodds (45:57):
Yes.

Michael Jackson (45:58):
I really think funding is all about aligning incentives, right?

Kent C. Dodds (45:58):
Yes.

Michael Jackson (46:02):
Somebody comes along, they say, "I value what you are doing, therefore, I'm going to pay you to work on it." And I say, "Thank you. I'm going to take that and I'm going to use it. And now I can keep working on it full time." And now we are aligned, right?

Kent C. Dodds (46:02):
Mm-hmm (affirmative).

Michael Jackson (46:16):
But I can't rely on somebody's sort of goodwill to say, "Oh, hey, I think Michael needs some extra money to go and work on React Router. I'm going to go kick him a donation on open collect." That's nice and thank you for doing that. But that is not a sustainable way to sustain open source. And we've seen it with just recently the Babel project, which is a project that literally anybody who is doing anything with the web these days, anybody, all of the Fortune 500 not just a significant percentage of them, 100%, no doubt, are taking advantage of that project specifically.
And needless to say, countless other businesses, medium, small businesses, whatever. And they're struggling to fund the project. And it's a shame. And it's happened time and time again. It happened with open SSL and it's not right.
And so, what we're doing is we're aligning incentives between us and between people who value what we're doing. And so far, it's working out incredibly well. We've had a great response from people who they want supported good quality tools and they want a team that's dedicated to working on those tools full time. if you're going to build your business on Remix and you're paying for it, you're actually going to feel great about that because-

Kent C. Dodds (47:49):
I do.

Michael Jackson (47:50):
Yeah, actually, because you're helping support the team that's doing it. I mean, I feel good about that. If something is free, I'm always like, "Well, how's it funded?" Because it's going to take somebody to work on this. So, that's our model, is our model is that we are going to ... We're selling Remix.
Of course, we have a trial period. So, we have a period where you can go ahead and buy it. You can test it out. If you don't like it, for whatever reason, we won't ask you any questions, you can get all your money back. No harm, no foul. But we think that it's going to provide you significant amount of value, that you're going to want to stick around and you're going to want to hang around for a little while and use it with us. So, we'd love to have you. I think, did you want to get into the homework?

Kent C. Dodds (48:46):
Yeah, yeah. So, I just wanted to say one quick thing on this.

Michael Jackson (48:46):
Sure.

Kent C. Dodds (48:50):
And that is, when I become a user of open source software, I become a drag on that maintainer, something that makes it harder for the maintainer. I'm sucking energy from the maintainer. But when I-

Michael Jackson (49:05):
You're asking a question on GitHub. You're opening an issue or something, right. And they have to respond to you. Right?

Kent C. Dodds (49:10):
Exactly, yeah, exactly. And so, when I become a user of Remix or a paying customer, I'm actually making that project better. And our incentives are aligned. I want to give a better product and I give you money, so you can make it better. And so, I, as a user of Remix, just love this payment structure. I paid way more for the laptop that I'm using. I feel like it makes a lot of sense to pay for the tools that I use.
So, yes, let's wrap this up. We're way over time. This is a great, great chat. So, for our homework today, we just want you to go through the Remix tutorial. So, you go to Remix.run, go to the tutorial and go through that. Try it out. Get that free trial license if you don't already have a Remix license. Give it a shot. And I think that you're really going to find that Remix is just a really special piece of software. So, anything to add to that, Michael?

Michael Jackson (50:14):
No, that's it. You said it perfectly. Thanks again so much for having me on the podcast. I enjoyed our chat very much and I enjoy seeing everybody in the Remix discord channel.

Kent C. Dodds (50:25):
All right. Thanks, Michael. See y'all later.

Michael Jackson (50:28):
See ya.