Transcript
00:00 Hey, everybody. I am so excited. I'm Kent C. Dodds, and I am excited to be joined by my friend, Lee. How are you doing, Lee? I'm doing great. Thanks for having me here. Thank you so much for coming. So, most folks probably have seen you around on the Internet,
00:18 Lee Rob on X with three E's, I think. Is your middle initial E, like is that your middle name? No. For some reason, the Lee Rob with two E's was taken on X, but the account is just
00:34 gone and suspended or not there. So, I'm hoping one day I will get it. One day I will secure it. Okay. Well, for now, I think it's not too hard to find you. I would love for everybody to get to know you a little bit if they don't know who you are already. So, could you give us an intro to yourself?
00:53 Yeah, of course. I am first and foremost a front-end developer, product developer, someone who cares about building great user interfaces, and an optimist technologist. I love technology
01:08 for technology's sake, but I also like the end products that you can create with it. That was really what got me into programming in the first place. I have been building with React since pretty early on, not as early as you or not as early as some of the others
01:23 in the community, but I remember it was really the first time that made me enjoy the JavaScript ecosystem. For all its faults, for all its flaws, React was the thing that really was like, you know what, I think this JavaScript thing is not too bad. So, yeah, that's me.
01:41 I work at Vercel. Awesome, yeah. And what is your role at Vercel? Yeah, so I've been at Vercel for about four years, primarily doing education, documentation, helping build the community for Next.js, and just trying to teach people about how our
02:00 products work, how the frameworks work, and get them excited about programming. Yeah, super. That's awesome. And you do a really good job of that. I hear from a lot of people that they are really impressed with the way that you conduct yourself online,
02:18 on X and otherwise, and then just the massive undertaking that it is to support Vercel's documentation, not just an entire framework like Next.js, but the entire infrastructure
02:33 offering that is Vercel. And in particular, because Vercel is built on top of yet another complicated piece of technology, or group of piece of technologies, that's an enormous undertaking that I'm just amazed that you're able to manage it all.
02:53 Thank you. Yeah, I appreciate that. There's a lot, but it's fun. Yeah, that's awesome. So, yeah, I would like to talk with you, Lee, about React 19. So you said you haven't been doing React for quite as long as everybody else, but I'm pretty
03:08 sure you've been in React for quite some time. What year did you first get into React? Yeah, it was really, I would say, 2015 was really when I started to start building React
03:23 for my job at the time. So they were pretty decent early adopters of it, and have really been building with React since then. I've used other tools on the front end in some bits, but React has kind of always been my go-to tool for building UIs.
03:40 Yeah, yeah. So I think then you've probably been using React just a little bit longer than me, because I started using React for my work at the end of 2015. But still, I kind
03:56 of feel like an OG, because that was pretty relatively early, considering that React is now 11 years old. So I've been doing this for a long time, and so both of us have seen evolution of React, and new features and deprecation of old features, and everything in between.
04:15 And so that, I think, contextualizes a lot of your excitement around React 19. Before we get to React 19, because you have all that history with React, I want to know what were some of the really impactful things that happened in the React ecosystem? Not necessarily
04:33 just in React, but the entire ecosystem over the last few years. I'd love to talk with you about some of those. So what were some of the most impactful things over the years? Yeah, having the privilege of being in the React community for some time, I mean, going
04:50 as far back as Hooks, I remember making PRs to our code base at work, and just moving from class components to Hook, and deleting code, and feeling so good about not only making our code base more maintainable, but also catching and fixing some very subtle bugs.
05:09 And pretty quickly after that, when the ecosystem started to build all sorts of great abstractions with Hooks, we could just rip out a whole piece of code that we had in our product code, and replace it with this really nice abstraction that was way better, that somebody else had spent a ton of time building on. So that was one of the, I think, a really pivotal
05:29 moment in the React ecosystem. I feel like over time, the quality of the community has really made building on React a lot of fun. And not just the people in it, but the ecosystem
05:44 of packages. Because the Hooks were kind of this foundation for five, six years of just awesome community libraries, and frameworks too, that were building on top of all of these features to deliver some really interesting stuff. I think that kind of led us up to,
06:03 let's call it like React 18-ish. And then I think since then, React's philosophy changed a little bit. To me, it was like, for a while React was having a very thin core, and really
06:19 allowing the ecosystem to build a lot of abstractions on top of these really solid core APIs. And then within the past, let's call it like three, four years, I feel like there started to be more and more abstractions built into the React core itself. And I really
06:39 like Ryan's talk that he did at HTMXConf, Big Sky Conf, Mind the Gap. Because to me, I resonated a lot with that talk. It's like React is starting to have more of an opinion about the network. It's starting to have more of an opinion about how your front-end and back-end
06:56 communicate together, and how your client and server work together. And that means new APIs, new service areas, but it's all within the same React model. The same abstraction,
07:07 the same components. Absolutely. And what's interesting is those new API, that new surface area that is getting added to React that some people are reasonably concerned about,
07:23 those are serving use cases that if React didn't support them, a framework would have to serve those use cases. And so that API surface area, it needs to exist somewhere. And so what's really
07:38 neat about what's happening with React 19 is that they're just shifting that fragmentation of handling those use cases. They're combining it into a single core package of React so that everybody is kind of on the same page in regards to that. And then the things that really are
07:57 outside of the purview of React can continue to be different, and that's what frameworks do. But I think that there's a lot of value in bringing the community together once a very
08:12 clear path has been established. And so React taking over things like forms and even data loading with RSCs, that is just a huge, huge benefit to the community, whatever framework
08:30 or flavor of React you end up using. Because up until React 19, you've got lots of options for React. And options are good. We're working on pushing things forward, but it's going to be so nice when you're looking at somebody's editor and a React component,
08:50 and you're not sure which framework they're using. You just know, oh, this is React code. And then on top of that, just the ability to share code across different frameworks will be a really nice change. Yeah, I agree. Something I was thinking about this morning was,
09:06 like, I don't really remember. It's probably on one hand, the amount of React bugs that I've ran into over the years that were React core issues. Most of the time, it is something that
09:22 has to do with a framework or a tool extending the React model. So it's like server rendered hydration errors or something like that, which has been a pain. And even now, React is starting to give better utilities for understanding hydration mismatches. But really, the core
09:37 surface area, I feel like they really have done a good job of making sure it works really well. Yeah, absolutely. And on top of that, React 19 comes, to speak specifically to the hydration stuff, comes with a lot of improvements on that specific error, too, which is quite nice.
09:59 I wanted to back up a little bit and ask you about your journey into finding your way at Next.js. And were you a user before, and then you got hired over at Vercel? Or did you become a user as you were working at Vercel? I'm curious to hear about that Next.js origin story for you.
10:16 Yeah, so started with React in 2015. I was actually doing, it was mostly bespoke React with your own bundler setup at the time, as most people were. Then about 2017, going into 2018,
10:33 I joined a different company, and they were on a custom React server rendered setup with Webpack and Babel and all the goodies, of course. And we worked on a project. One of the things that me and
10:49 some other folks on the team did at the time was moving from that custom world setup over to Next.js. So in 2018, Next.js was still pretty new. It came out in 2016. So there were still some rough edges,
11:03 but it was much better than us wanting to spend time worrying about bundlers or compilers, because the Next.js setup for Webpack and Babel was basically the exact same thing we were going to do anyway in our own setup. And we got some other goodies out of the box. So I helped my
11:19 company transform our React app over to Next.js and worked on that for about a year and a half. And along the journey, because it was so new, there wasn't really any content about how to do a lot of
11:35 very common things. So I would build something, and I would run into an issue, and I'd Google it, and it just didn't exist. So I was like, okay, I'm going to just teach people about how this stuff works, and ended up doing that for a while until Tim on the Next.js team messaged me and was like, hey, have you ever thought about just joining us and doing this full time? And I was like,
11:56 it's not a bad idea. At the time, Vercel was very small, though. It was only 30 people, so it was much different back then. But overall, it's been a lot of fun. Oh, that's awesome. Yeah. Those are my favorite kinds of, and now I work on the project stories,
12:15 because for a couple of reasons. For one, it just demonstrates a real genuine love for the project itself, rather than like, oh, I came here because there was money. I mean, I'm sure you appreciate
12:30 the money, but you were already motivated to work on the project before, which I think is great. And it also is an inspiring story for anybody who is getting into working on frameworks and things,
12:48 that there is a path to contributing a greater deal in whatever thing that currently catches your eye of interest. Recently, somebody asked me, I was told that getting into open source would
13:05 be a good way to find work and stuff. How does that work? And I said, well, you just look for the companies that you're interested in working at and start using their software and contributing to that software and rub shoulders with the engineers who are working on that software. And so it's
13:20 always really great to hear stories from folks where that was how that came to be. Yeah. And I'll be the first to admit, I am not the world's most leading expert of how to build the best front end in the world. There's definitely people who are better at this than myself. I think
13:40 that I have some good opinions and I care about this stuff, but it's very humbling being around people who create frameworks and who are very in the weeds on a lot of these very complex things. I get to learn a lot. And I think that my perspective that I can bring as the person
13:57 trying to teach other people the tool, who maybe isn't the creator of the thing, but is somebody who is passionate about it and wants to help other people learn it, just gives you a unique and different perspective. And I give that advice a lot to people wanting to get into open sources.
14:12 You can feel very imposter syndrome-y because you see these very technical, very advanced people, usually further along in their career. But what you have is something that they don't have, which is a lot of time to go help with the community, to look at issues, to make reproductions,
14:28 to build examples or help solve problems for other folks, maybe in a chat forum or something. So there's lots of ways to get involved. Oh, that is such great advice. Yeah, absolutely love that. Going a little bit more into that, some folks listening might have their
14:48 own projects that they're working on and are trying desperately to find people who are going to contribute in that way, or at least people who are going to care enough to use it and maybe write some content about it and that sort of thing. What are some of the bits of advice that you can give
15:06 in your experience of building up a community around a project and enabling the community to contribute back? Yeah, it's a good question because I really spent a lot of time on this in the early years of Next.js, and I still spend time on it
15:24 to this day trying to help people feel like their contributions matter in the community and encouraging them to do more, to create more, to help others. I think there's kind of two sides
15:40 to this. One is that people who already have the desire or the hope to go create something and they go put something online and they put themselves out there already. For those group of people, it's more of the support and reinforcement and assistance to tell them, hey, this is great. Thank
15:56 you for putting this out here. Here's some suggestions, like giving them some positive feedback and some positive suggestions. Maybe I would have done this different. By the way, we have this API that gives you X, Y, Z benefits that you might not know about, and just making them feel heard because they want to hear from you. They want to hear that their work
16:13 matters. That is one side. Then the other side is the people who aren't yet activated in the community. They're kind of like on the outside. Maybe they've built an app with your tool of choice before. Maybe not. For those, I find the best way is actually just getting out and talking
16:30 to people, whether it's conferences or meetups or online events or your local hackathon. Most decently sized metros in the world have some kind of local programming meetup of sorts,
16:46 very niche or very broad. You might find a lot of like-minded people there who you can learn from and build a community with. I like that suggestion. Actually, I think you're
17:02 pretty uniquely positioned to address this other challenge that I've heard people talk about when we talk about going to community events, and that is people who live in relatively remote areas. They don't live in a large-ish metro. What are good ways for those people to
17:18 get involved? Also, for folks who are trying to get those people involved, how can you get that community built from people who are in remote areas? Yeah, I can share what worked well for me
17:33 and could maybe be helpful for others. For context, I live in Iowa in the United States, which is right in the Midwest, close to Des Moines, the capital. It is not a tech hub. It's not a tech mecca, but there are people here who care a lot about technology. When I was getting started,
17:54 I was not only learning a lot from my co-workers at companies in the area who also cared a lot and had a lot of experience that they could share with me, but also I was kind of augmenting that with online communities. I think there's a place for both. I would go to our local JavaScript
18:11 meetups and I would talk to peers and more mentors that I had at my jobs who were 10-plus years ahead of me in terms of their programming experience and try to learn from them how they progressed in their career. But then online too, I would try to stay up to date just on what was
18:32 happening in the ecosystem. I would go to conferences or I would watch conference talks. Going to actual conferences isn't always an accessible option for everyone, whether it's the location or the cost. Thankfully, there's lots of great content online that's made available for
18:49 free. There's courses that can help really level up people that can be available through various different ways. I believe you do purchase parity pricing as well to try to help make it accessible
19:06 for folks around the world too, which I think is awesome. So kudos to that. And I think just learning and ingesting all of that knowledge gives you an opportunity to give back to your own local community as well. I remember doing talks about design systems and component libraries in our local meetups here in Des Moines based on the stuff that I had learned
19:25 applying it at my job, but also reading a bunch of articles online from the team behind styled system and stitches and theme UI and trying to remember emotion, style components, max. I
19:42 remember learning so much from all of them online and then kind of making my own opinions and putting it into my own derivative work. Awesome. Yeah, there's a ton of opportunity wherever you are in
19:58 the world, and I think people should take it. So, Leah, I wanted to also talk with you about the, well, I want to say future of React, but the fact is that you have been living in the future
20:13 of React for a while with Next.js, having shipped the Canary version of React bundled with Next.js. And so tell me about the future because I haven't been using these features. I've been looking at them and playing with them. And Epic React is framework agnostic outside of React, so it's not
20:32 using Next.js or Remix or anything. And so it's really just focused on React. And so through Epic React, people are getting what the latest is. Everything is React 19 in there. But yeah, I want to know from your perspective, having worked with these technologies in production
20:50 environments so far, what are the things that you're most excited about with what we get out of React 19? Yeah. So for a bit more context on the Canary bit, going back probably three years
21:07 or so, Next.js started in 2016, but we were trying to figure out the next evolution of where we wanted to take the architecture of the framework. At the time, you know, in talking to the folks on the React team, they had some pretty good ideas for how they wanted to have more of an opinion about
21:24 the network, how to do things like server components and actions. And we kind of took a pretty big bet to say this vision seems pretty compelling. I think where they're headed makes a lot of sense, but it's going to take a lot of work to actually work with them and build a lot
21:41 of these APIs, not only for Next.js itself, but for React and for the general community. So we started working with them, and they built this Canary channel, which this Canary release channel was designed for frameworks to be able to use some of these new features and bundle them into their
21:59 own library or framework with their own semantic versioning. So what that means is that this newer version of Next.js called the App Router has been able to use some of these React 19 features for, you know, as they've been released, let's call it like a year, and varying levels of stability
22:18 depending on the feature. And that feedback from people trying out the early versions of some of these things has been able to help influence some of the direction, as well as the broader community
22:31 reception to things like the directives for use client and use server actions, both on the server and on the client. And I think the thing that I'm most excited about that I don't think was as
22:45 apparent at the time, because it's kind of a chicken and egg problem, but when we talked about server actions at first, it sounded a lot like, okay, this requires a server, this is a framework thing, is this a Next.js thing, or is this like a React ecosystem thing? It sounds compelling.
23:04 I can just call a function, I don't have to do the ceremony of use effect or pull in an external library to like connect my front end and my back end, my client and my server. But then over time, and as the rest of the React 19 story has been told, it really goes to show the foresight
23:22 the React team has had in designing features that work seamlessly across the client and the server. So it wasn't just about server actions, even though those are great, it's also about client actions. It's about being able to have the same programming model, both on the server and the
23:40 client. And I remember I did a live stream a few months ago where I was building a React and Vite application, just using Vite for my bundler, just basic client-only React app, using React 19. And using actions was so nice, using things like use optimistic,
23:59 and some of the new form hooks. It's so awesome that all of this works, regardless of the framework that I want to use or additional other features I want to use. It's like now baked into the library itself. And there's definitely ways that, whether it's Remix or
24:14 Next, or the Next framework can integrate and extend and expand and do more stuff, for sure. But it's awesome that we have these new primitives in React itself. So I think the form hooks, in particular, I'm excited about because there's a lot of new
24:33 patterns that I think have been lifted from the existing React community and libraries that have existed. And a lot of the good parts, sometimes that were hard to do without native integration into React itself, are now built into a pretty nice abstraction.
24:52 Yeah, yeah. I completely agree. I recently shared on X that we have form libraries and they're awesome, but they're going to need to adapt to the new React model or just simply be uninstalled because React has just built in so much really awesome functionality that
25:09 you need to integrate with. And what's so interesting is that the form model integrates directly to the transitions that React added years ago. And so it is so good.
25:30 The team is really brilliant being able to make all this happen in, frankly, a pretty easy to migrate way. So even the code that you and I were writing back in 2015 still will work in a
25:46 React application. There are, of course, breaking changes here and there, but the mental model is largely the same. Hooks were a big impact, but still those class components are going to still work. And a lot of it speaks to the constraints that meta has in not wanting to break a bunch
26:06 of things, but that has been a really positive thing for the ecosystem. And yeah, I'm totally with you that it's actually really cool we can use this stuff without a framework. And it's just like a regular client-side app and you can still use all this stuff. Now, of course, you want to use RSCs and stuff, then that's going to require a lot more effort and a framework is
26:27 definitely recommended there. But I love that we have this capability now. That's half of what you are doing when you're building a React app is the mutation side of things and React making
26:40 that so much easier is something definitely to be excited about. Yeah, especially because, you know, to your point about generally, I think when folks use server components, they'll probably use a framework or a routing library that integrates well with the bundler.
26:59 That's half of the story, right? Like to your point around mutations and things that happen on the client that are more for the interactive bits, there's still so much to happen there that it's great that all of that works without having to integrate with many of those things
27:14 and is portable and reusable across different tools. And I think we'll see a whole new set of abstractions in the ecosystem as well. Like you said, some of the form libraries will evolve or new ones will come out that kind of simplify some of the common things folks are doing to extend
27:32 the model. Mm-hmm, 100%. Well, sweet. Was there anything else, Lee, that you wanted to talk about before we wrap things up for the day? I think the only other thing that is interesting you mentioned that could be helpful to talk
27:50 through is transitions. And I think, for me at least, it was kind of this strange thing that the React team announced. I didn't really understand how it all fit together into the
28:02 bigger picture. But now that I kind of see how all of the pieces fit together with some of the newer form hooks, actions, transitions, and really the end goal, in my opinion, of
28:21 allowing the user to not block the UI when doing some bit of work. And if something more urgent comes in, you can kind of choose to do that work instead. Some of those are really hard problems
28:36 to solve. So it's nice that there's now built-in primitives for solving those pretty common UX patterns, I think. Like you start to do some kind of search input or filtering, and these things come up. And there's been abstractions that have thousands of lines of code that try to do
28:53 what these now built-in utilities help solve. So I think the biggest mental model shift for me was a lot of folks are used to the world where you're using the browser navigation to move between routes. You see the loading spinner. And then now we have these transitions that are allowing you to
29:11 do these moves between state, basically, in your app. And you're in control of how you display that pending state. So you get to put the inline loading spinner, or you get to make the pulsing animation on your list, which is really powerful. It just takes a little bit of understanding of
29:28 the practical use cases of the pattern. Yeah, absolutely. And Epic React has this workshop all about this. It's the React Suspense workshop. And hopefully that helps open people's
29:44 minds up to the possibilities there, because I do agree. I think we'll be discovering new patterns and practices years to come, not just with the transitions, but also with all the form stuff that hooks into the transitions. There's a lot to be excited about. I'm glad that you brought
30:01 that up because, yeah, use deferred value and use transition, use optimistic, and use hook as well. There's a lot to all of this stuff. And honestly, it blows my mind how easy,
30:18 once you have that mental model and you understand how that all works, how easy it is to just, oh, you know what? That's not operating the way I want it to. I'll just throw a suspense boundary around that. Or, oh, I want to handle that error a little bit nicer. Let me declaratively add some error handling to that. We've got a pretty good library here for UI. Totally.
30:41 So, Lee, thank you so much for giving us your time today. This has been really awesome to have you here. And I'm just really looking forward to the future, looking forward to seeing you in person again. And hopefully folks can reach out to you and connect with you. What
30:59 is the best way for them to do that? Yeah, absolutely. Thanks for having me on here. Absolutely. Thanks for having me on here. If folks want to reach out, lerob.io. If you want to go to my site, it's got all my socials on there as well, and a guest book if you want to sign it, like the 90s web. So, that's the best place. Perfect. Thanks so much, Lee. See you all later.