Video details

Kent C. Dodds - The stack of the Future - React Miami 2022


Kent C. Dodds - The stack of the Future
When a brilliant idea strikes, you want to hit the ground running and focus on building out your idea. Unfortunately, for any ambitious project, it takes a significant amount of time configuring the tools you'll ultimately need to make your idea a reality. Far too often we either under prepare and our MVP-shortcuts end up being a pain in the neck for the next few years if we're successful, or we spend so much time in the setup process that we lose all motivation. In this talk, I'll show you how Remix can help you get started with a solid foundation so you can focus on building out your ideas. And when your MVP turns into a money maker, you won't feel like you have to rewrite your app from scratch! And for those of you starting new projects from scratch on a regular basis, I'll show you how you can make your own Remix stack to create these projects just like you want them again and again.
NEXT EVENT: JSWORLD Conference from 1-3 June 2022 -
Powered by
#reactmiami #jsworld #jsworldconference #frontendlove #frontenddeveloperlove #javascript #reactjs #angular #react #vuejs #vue #vue3 #typescript #graphql #jamstack #amsterdam #conference #svelte #sveltejs #next #nextjs #staticsite #css #html #nuxt


Hello, everyone. My name is Kentucky Dodds and I'm so excited to talk with you all. Yeah. Thank you. I'm so excited to talk with you all about the stacks of the PC future. I am the Director of Developer Experience at Remix. I joined up with Remix back in November. I also created Epicreact Dev and, and I get super nervous in front of hundreds of people. I don't know about you, but one of the things that helps me is by making you all do something that will make your day awesome, and that is to exercise. If you're physically able, I'd love for you to please stand. We're doing this. This thing is happening. Okay, put your arms out in front of you like this and squat down and come back up. This is called an air squat. And that was your bonus because we're going to do twelve of these together. And I want you to count out loud with me. Ready? One, two. Now you got to count out loud. It doesn't work if you don't. Let's start over. One. No, just kidding. Four. Five. Six. We're not very synchronized. Seven. 8910. We're getting close. Eleven and twelve. And before you sit down, stretch up over your head as you can and switch over to one side and over to the other. I know most of you were not yoga, so this is yoga. Okay, before you sit down, turn to the person next to you and thank them for coming to the conference. Now, Ben is getting wired up right now and he also does air squats. So I don't know if he's still planning on it, but yeah, look forward to that, maybe. Okay. I like to start out with expectations because my talks are not typically the sort of thing that you can both be on Twitter and pay attention at the same time. And so I just want you to decide right now whether you're going to do one or the other because you can't do both. What we're going to be talking about is I want to try and inspire you to build your weekend ideas. And I want to give you a bit of an introduction to Remix. I'm hopefully not going to make this boring, so hopefully I'm just trying to lure you away from Twitter and we're not going to be talking about framework wars. I prefer to just talk about why I love Remix so much. So I know a lot of you are starting to wonder, how is this different from another framework that I really like? I'm not going to really talk about that. So let's get started. What is Remix? Remix is a web framework, full stack for developing high performance, really excellent user experiences on the web. And one of the things that I say about Remix, one of the things I love about Remix is that it enables me to build an excellent user experience and not be ashamed of the code that it took to get there. I am floored. So I joined up with Remix because I rewrote my website in Remix, and I was just so blown away that I didn't want to teach anything else. I was like, I have my testing JavaScript, I got my Epic React, and at some point I need to get those things updated. But all I want to do is teach Remix. I don't want to spend time teaching these other things. Like, these other things are still really interesting to me, but I just want to teach Remix. And so that's why I joined up with the company. And so, yes, I realized that I could have ulterior motives and telling you how great it is because now I'm part of the company. But if you're worried about that, you can go watch talks that I gave before I joined the company, before I even was thinking about it. And I was just as enthusiastic then. So there are two priorities I want to talk about for Frameworks. One of them is the getting started experience. You want it to be as amazing as possible, and the other is the ability to adapt to changing requirements. And I would argue that the second one is probably actually more important because we do that a lot more when you sit down at your desk, unless you're like a proof of concept churner where you just like, that's all you do all day. You're probably working on existing code. And that's the thing that Remix just totally nailed. And that's why I decided to join up, is because I can change my existing code without having to open every file on my project. I don't want to throw any state management libraries under the bus, but there was one state management library that I used where I need to just change one little thing, and I had to open every single file to follow the flow of the code. And it was just not fun. Remix, it does not feel like that at all. In fact, in Remix, it doesn't feel like there's application state management at all. You're not thinking about application state management. It's amazing. It's so cool. So Remix stacks. You know what? I forgot to ask a question at the start of the talk. How many of you have here? Raise your hand if you've heard of Remix before. Okay, that's good. Keep your hand up and keep it up if you have used Remix. Yeah, that's more what I was expecting. All right, how many people have shipped Remix? All right, you're my people. Hopefully next year we have more. Hands up. It is pretty new. It was just open source in November, so it is relatively new, but it's growing fast and it's amazing. Okay, so on March 17, we released a new feature for that first priority of a web framework, and that is to get started really quickly. So I'm going to talk about a couple of things with stacks. One is how it enables you to build quickly. It allows you to build solidly. And I'll explain what that means. Because it's using Remix, it adapts to change really well and they are also customizable. So these are the things we're going to talk about. So first on the Build quickly piece, we're actually just going to watch this video that I recorded because it's like way easier. Is that okay? Are you feeling jipped on two minutes of your life? I hope not. It's not going to let me go full screen, though, which I worried about. And so I prepared. We're going to get the Remix indie stack deployed in less than two minutes. So first we're going to copy the Create remake script and set our Onewheel Store as a folder. This is going to run the setup to get everything installed and set up. We'll just speed this up a little bit because running the end to end test as part of the setup is kind of nice, but a little slow. Let's open our editor. We're going to log in with Fly. You'll want to create a Fly account. And then we'll log in with hello at Remix run. And next we're going to create the apps, both the production and staging apps. And then we need to create a GitHub repo and put our Fly access token in it. So let's create that Fly access token and then go and create our GitHub repo for the One Wheel Store. It's my One Wheel Store. We'll create this repository, go to the Settings and Actions secrets. We'll create a new repository, secret, put in our token, and grab the Fly API token name, which is all set up for our workflows. Now we got to set the session secrets. So we'll say Fly Secrets set session secret. Now we'll create the volumes for our SQL Lite database for both production and staging. We'll initialize our git repository, commit everything within it, and push that up to our One Wheel Store GitHub repo. So we'll copy this to add that remote, get that pushed up. And now all of our code is in that repo. And the action should be running. The action takes a little bit of time, especially the first time before you have a cache. So we're going to go ahead and speed this up just a lot. Yeah, we'll speed it up a lot. So after just a couple of minutes, when you can just grab a snack, you are totally done. You grab the app ID Fly dev. And your remake app is deployed to production. That set up experience is deployed to Fly IO, which is where I deploy my website. But Remix can deploy on anywhere. You can run JavaScript, you can deploy Remix. So Versailles, in fact, I think Netlify announced something just like yesterday. I wasn't paying attention, but they were going to. And it's going to be really cool. If they didn't, then I hope they don't get mad at me for mentioning that they're going to. But yeah, dino cloud flow workers you can deploy anywhere. And this particular stack shows you instructions on how to get it deployed to Fly. And this app is like a full app. Like take a look at this thing. We go to the deployed version of this. We have authentication. So if I go to Incognito it's going to take me. We have the full username or email password, authentication built in. You have a model for notes, create, read, update, delete all of that is supported. It has an arm like a database, all the things so that you can get started really quickly. This is your build a blog in 15 minutes moment with stacks. It's really awesome. And so getting started quickly, that's one piece of it. But what do you get started with? And that is the built solidly thing. So what do you get when you build something with Remix with the stack? So it's basically a code generator. That's pretty much what it is. It has a couple of really cool features that we'll talk about in a little bit but that's what we're talking about. And what it spits out at you is a remix app. So it adapts to change really well. We'll talk about that but a bunch of other things as well. So the app itself gets a 100 performance score on Lighthouse. As you would expect, Lighthouse is great, but it's running on your machine and all that. It's pretty limited on what it actually can tell you about the performance of your website. Webpage Test how many of you have heard of web page test? Okay, this thing is amazing. It's a really awesome tool that allows you to choose like some particular is my laser work. You can't see that at all. It allows you to choose some particular configuration of desktop or mobile, what version of browser it's using, its internet connection and where it is in the world. And it will run a test against your website. You can even set cookie headers and stuff like that, which is what I did here. So you can see what's it like for an authenticated user in X part of the world to access my thing on X device and so on. A reasonably fast device. And by the way, Fly can deploy to many regions all over the world. I deployed this particular app just to Dallas, Texas and so coming from Virginia to Dallas on a desktop with a cable connection, the application is really fast that you have your first paint in like here it's zero 2 seconds. It's about the same here. And then on mobile it's also still really fast and this is all server rendered. It's accessing actual user data from a database. Nothing is cached at all and it still gets on a really low end moto g that's a very low end device on a 3G connection in Hong Kong going all the way to Dallas. It still gets the site up in like 2 seconds. Lesson, it looks like 1.6 is where you get your first full render, which is pretty sweet. And because Remix embraces progressive enhancement, we actually don't have to wait for the JavaScript to load before the application works. So all the HTML loads onto the page, the entire application is usable, forms work, so mutations, your links are going to work, everything. So it's great to reduce the amount of JavaScript that you're shipping, but when you don't need the JavaScript for the app to work, you just need it to be an enhanced experience. That's what we call progressive enhancement. It's amazing. It's really cool. We've kind of thrown away progressive enhancements as an industry and I'd like to see that come back. So yeah, super fast, regardless of the device or anything. Actually, this is another thing that just occurred to me was by doing server rendering, you can have your fast server do all the processing and all that stuff and send the finished HTML to the browser. And so even if it's on a low end device, if it can handle HTML, then it's able to still be fast rather than having to download all the react and do all the compiling and rendering all that stuff out. If you want to hydrate, then you do have to do that eventually, but you don't have to wait for that to happen before the application is interactive. So it's super fast. This is what I mean by building solidly. And then it's built on top. The stack comes pre configured with all of these tools. Some of them you may recognize, others you may not. But I mentioned Prisma. It's using SQL Lite, by the way. SQL Lite is legit like you think, oh, that's just the thing you play around with every now and then because it's a file, right? No, this thing is nuts. So SQL Lite is awesome. We also have another stack that's similar to the Indie stack that deploys with Postgres. So if you're really like, oh, I want a real database. Yeah, you totally can. But yeah, I'm really impressed by SQL Light, but we have all the testing tools there's. Testing Library, how many of you using Testing Library? That's so gratifying. Yeah, I made that by the way. Yes, and oh, by the way, something that people don't know about testing Library is there's actually a testing library for Cyprus, and for Puppeteer, and for playwright, and for Angular, and for View, and all of the things anywhere you can find a Dom. You can get a testing Library implementation there. So if you didn't know that, now you know and you can enjoy those queries everywhere. It's awesome. Okay, so also GitHub action TypeScript, you actually have the option to remove the TypeScript. If you don't want to do that, some people still feel that way and I still love you so much. And then Tailwind, because it's amazing. I love tailwind. And then of course, Remix, which allows you to adapt to change. So a couple of the things that Remix enables, once you've generated the project, that code is yours, the stack is done. And now what you're left with is the need to be able to adapt to the changing requirements of your application. We generated a Notes app, but you're probably not trying to build a Notes app. And so how well does this adapt to change? So here are a couple of the reasons why Remake adapts to change. Really well, first of all, it's built on a web foundation. So I've got a little project here and I just want to show you a couple of the things that I really love about Remix as far as building on a web foundation. So for one, our authentication is based on its server side. So it's based on the authentication that we used to have in the good old PHP days. And there's no jobs in local storage that people can get with their price scripts or whatever. It's all Https or http only cookies. You are the one responsible for getting the cookie out of the request. And this request object, if we dive into the type here, let me bump that up, I forgot to double check that size, I apologize. But if we dive into the request object, then we're going to see that this type comes from Lib or what is it? It's TypeScript Lib. And so this is the fetch API request. So everything that you're doing in Remix is using what a lot of frameworks do. And what I have done in my abstractions is I will take a web platform API and I will wrap it with what I think is a nicer API. Remix decided to go the other way and instead expose that API to you. So Remix job is to take whatever request is coming in and turn it into something that is web platform and just hand that off to you. This comes with a lot of really great benefits. One of them is abstraction. Like, you can build your own abstractions around that. But the other is, as you learn Remix, the better that you get at Remix, the better you get at the web platform. You become a better web developer just by using Remix. This is actually what I like about React as well. When I was using Angular GS and I switched over to another company that was using React, and I was really sad that all of the knowledge that I had accumulated around angular JS was going away. It was really disappointing. And when I started using React, I was really excited that I needed to spend a couple of hours learning JSX syntax. And then everything else is JavaScript. I was using maps and filters and all of this JavaScript syntax that I'd never used before. In fact, it's funny how I got my job at PayPal was because I tweeted about object spread syntax and I tweeted something about JSX and spreading props. I was like, It's a shame that I won't be able to use this much because I use AngularJS. And my future coworker at PayPal replied and said, come work at PayPal and then you can. So, yeah, I literally got my job at PayPal because I complained about being able to use JavaScript features. So, yes, the more you learn Remix, the better you get at the web platform. And this is actually one of the reasons why we say Remix is not just another web framework. It's a web framework that exposes the web to you. And you get really good at the web when you're using it, so it's not just requests. And this is all server side too. So we probably fill all of the fetch APIs and web platform APIs for you. And that is pretty cool. There's something else I want to mention, but I just remembered I mentioned it later, so I'll save that. Okay. The abstractions that you have are simple and pretty minimal. So, again, here in this session, we don't have an authentication abstraction. There are like other people have made authentication abstractions, but we don't ship one. What we ship is ways to interact with session storage. So you can have session storage and postgres, or you can put it wherever you want. I'm using cookie session storage here, but we provide minimal abstraction so that you find yourself spending more time in the Mdn docs than you do, like the Mozilla Developer Network, like the web stuff than you do on the Remix docs. And a lot of people have expressed that's been the case for them, which I think is really key. So the abstraction we provide are simple and minimal. And then we give you the static site generation benefits without the compromises. Static site generation? So what do I mean by that? Well, for one thing, Remix is 100% server side rendering. There is no static site generation with Remix. And this is very intentional because SSR is more powerful 100% of the time than SSG. That's just a fact. Like, you can't get around that it's more powerful. But the reason we do SSG is because there are a lot of benefits with being able to just generate some static files and send them to a CDN, right? And some of those benefits are, well, we have reliability because now we don't have a server we need to worry about managing and stuff. It's maybe easier to deploy. Well, a lot of really cool companies have made it quite easy to deploy, like an actual running server, whether it be serverless or otherwise. And then if you use cache headers properly here I made an about page where I just specify some headers for this page, and I say, hey, I'm going to set a cash control with the max age of an hour and snacks that's shared for a shared cash max age of one year. And then still while we validate for a week. So I'm willing to give people a stale page for a week while we're revalidating. That's actually pretty high. Probably, like 60 seconds of, you know, all that you do is you ship your server running, whether it's serverless or otherwise. And then you stick a CDN in front of it, and then the CDN will say, okay, I'll just cash this thing for a year. And then you deploy an update or something, and you go tell the CDN, hey, I want you to purchase that. And the next user who requests the page is going to rebuild it. So your server is effectively a build server that just runs forever. And of course, you can be the first user. So you say, Hey, CDN, this page is now stale. And you say, Oh, by the way, can you give me that page? And so you're the first user to experience however long it takes to build that page. And because you have staledate, your end user should never actually experience this slow page. So the really nice thing about this is that when you build with SSR, which is the more powerful option, then when you later decide that somebody comes and says, hey, you know, this about page is pretty cool and all, it would be way cooler if we had the user's favorite animal on the page. I don't know. Wouldn't that be cooler? Wouldn't you like your favorite animal? No, that'd probably be really creepy. But like, if you selected it so we wanted some dynamic stuff. So if you went with SSG at the beginning, now you have to re architect the whole solution. You're like, Oh, man, now we need well, actually, what normally happens is you say, wow, it's too hard to redo this as SSR. So I'll just put a loading state in, and now we have something. Should I call them out? Never mind. I'm not going to call anybody out. But there are some banks, one bank in particular that shows you infinity loading spinners. And I'm like, how are we okay with this? Is this okay? No, it's not okay. But that's what happens, is we start with something that's like, this is totally static. No big deal. And then product comes and says, hey, actually, we want to have some dynamic stuff that's like, user specific. And you're like, Well, I can either do a loading spinner and finish this today, or I can rewrite the thing so that it can be server rendered. You don't rewrite everything, of course. Like, it's still react components and stuff. But the mental model for static site generation and SSR is very different. So if you start with SSR and you just use Caching headers, you can get all the benefits of SSG without the compromises inversion of a control is another key cool thing that I really like about Remix. And so that is, like I mentioned before, Remix will just expose things to you. In Remix, you're responsible for calling render to String or render to pipable or whatever the cool new things. In fact, when React 18 came out, all of Remix worked as is. You can use React 18 with old versions of Remix with the new streaming APIs and everything. And we've got some blow your mind stuff coming with the new streaming. React 18 is so cool. This is going to be amazing. I wish I could demo it for you, but we try not to talk too much about things that haven't shipped yet because we've seen what happens there five years later. I'm pretty sure this will be like in a month or so, but we invert control. So we say, hey, we called all your loaders for you, so we've got all the data and everything. This is for the server render. We do have client transitions and stuff, but for the server render, this is what gets called. And so now we want you to return a response. You can return anything you like in here, but typically you're going to return a response that is HTML with the markup and stuff. So I really like that. We also give you control over your hydration. So if you need to wrap this in a provider or anything like that, there's no special fancy file or anything like this. I suppose this is technically a special fancy file, but it's in every single project and so it's convention based and very obvious what to do. And then you're responsible for everything that gets rendered between the open HTML and the closing HTML. So on my website I actually have my last name is controlled by State, which I think is kind of cool because normally you do a use effect for updating class name on the HTML element. And so, yeah, you're in control of all that. We have nice little abstractions for adding meta. This can apply to any route that you're on. So you can change the title. Like if we go to log in, then we have a meta right here to say, here's what I want the title to be on this page. It's really quite simple and all that you have to do is render this meta component and then Remix will take care of putting the right meta things in there as well, the links as well. So here's how I'm getting tailwind on the page. You can also add prefetching links and stuff. And the really cool thing about this is if we go to oh, that's in a different demo, but you can have style sheets that are on specific routes that are only active on that route. And so you can put whatever garbage CSS you want in there. And you know, it only affects that route, which I think that makes style sheets actually kind of nice. When I was at PayPal, we shipped 90% unused CSS. Raise your hand if you know how that feels. Yeah, I know. Isn't that the worst? And so that's why we're like, yeah, let's jump on the CSS and JS train. I built a CSS and JS library. I know, and Tailwind is the answer, but if you want to use style sheets with Remix, you can. It's really great. I just noticed my time is up, so that's my bad. Sorry about that. I don't like going over. So sorry. Just got so excited talking with you. So yeah, we also deploy everywhere. I mentioned that already. And nested routing is holy smokes. Amazing. You've got a team that's responsible for the shell of the application, teams who are responsible for individual pages and they don't have to pass props or do any of that stuff between each other. So all of the problems that leads you to want microfront ends, they are not as big a problem when you're using Remakes. Really awesome for teams. So, yes, it allows you to adapt, to change. It's also customizable. This is Stacks again, so you can make your own Stacks. We've already got a bunch that people have been making in the community. Really awesome. We have three that are built in. One for AWS, one with Postgres and Fly, and another with the Indie stack with Sequellight and Fly. But you can make your own. And with that you can specify a custom template and point to your GitHub URL or to a Tarball or whatever. You have a Remix and it scripts that runs on initialization, so you can even provision a database or whatever, like on your own infrastructure and stuff. You can ask questions like what region do you want to be in or do you want to be regional or whatever. We have an option to automatically remove TS, so if you have a TS config, we'll ask them if they want to remove the TS. And we'll keep your dependencies up to date. We're not going to make all your code still work, but we will update the package JSON when we generate the project. If you say like Star or whatever, we'll update it to the latest step. So that is Remake Stacks. Last thing I want to mention, this is sort of the last thing. The key takeaway here is you can build your ideas in a weekend and keep the code if you really nail it. So I want you to take that opportunity to build cool stuff and feel really good about it and just make the world better. So I want to just really quickly mention Remix. Comp May 25, and it's going to be amazing and I'd love to see you folks out there. It's going to be in Salt Lake City, so check that out. The last thing that I want to say is. You're a beautiful person. Thank you.