00:00 What is up, everybody? I am Kent C. Dodds, and I'm very excited to be joined by my friend Theo Brown. Hey, how are you doing, Theo? Pretty good. Fantastic to be here, man. Thank you so much. It's awesome to have you here. Thank you for coming. I'm excited to chat about all cool things, reacting to things.

00:18 I like to start out helping people get some context on our relationship and everything, so I'm trying to go back where we first interacted. Of course, we didn't meet in person first. I think the first time we met in person was, I don't remember if React Miami or Epic Web was first this year,

00:37 but it was this year at Wonder. Pretty sure it was Epic Web. Yeah. Relatively sure it was Epic Web. Yeah, I think so. Yeah. So, like, April this year. But I knew you online. I think it was probably like 2021, sometime around there.

00:56 You were very early to catch on to what I was doing. It's weird to think now, but I only started posting videos, like, seriously, in April of 2022. I'm a bit over two years in. In 2021, I had 50 followers on Twitter. I was nobody.

01:11 But I got real lucky with a couple people in the scene that were super kind to me early. I loved Ryan Carniato and Fred Schott's blog posts. Fred's the creator of Astro and Ryan's the creator of Solid. And I reached out to both, offering some feedback on the way they wrote the posts,

01:31 just, like, little wording things, ways to format sentences better to make it a little more readable. I've always been nerdy about presentation and how people perceive the words that they're hearing and understanding. And they both were super receptive to that, were really cool about it, ended up liking me a lot, pulling me in for feedback on things early.

01:48 Eventually, I saw our mutual friend Tanner Lindsley was doing a Twitter space about just general web dev stuff. And I joined and asked him about a proposal I had written called Use Backend Query. That was a compiler hook that would let you write a React query hook in a component that would then compile out to an endpoint and call it with fetch.

02:07 He told me about two things he had heard about, Blitz.js and TRPC, asked if I was down to look into them and report back my findings. So I did that. He ended up loving me for doing that and pulled me in hard. And those were, like, the three people that really pulled me into the scene early when I was a nobody. And you caught on right around then.

02:26 Like, when you saw Tanner repping me and the cool community around me, the people who I'm still honored to support me, you jumped in really quick, too. And it meant a ton, because I've obviously been reading your posts, using your materials, and learning React through your work for the better part of a decade now. Yeah. Wow, man. That's awesome.

02:45 So that's the side of the story I had never heard before. So thanks for taking us through that. And that's very nice of you to say. I'm glad that I had a part in that story as well.

02:58 I would love our audience to get to know you and, like, who you are now and what you are into as well. Can you give us an intro to yourself? That's a hard thing to do in a lot of things nowadays. I used to work at Twitch. I was there for about five years.

03:15 Built a lot of tooling for safety, infrastructure, and primarily creator tools as well. I moved from back end to front end when I was at Twitch, and I still to this day don't know where I fit. I'm full stack in the sense that I'm ambidextrous. I'm equally bad with both hands. But it has worked out for me thus far.

03:34 I'm mostly known now for my YouTube channel and making content about full stack development. I cover all sorts of topics from, like, deep database. I cover a lot of different topics from chaotic database stuff to more traditional, like, React components, ShadCN type things.

03:50 I care a lot about developer experience and how it enables better user experiences. And I am known for being the main TypeScript, JavaScript guy on YouTube nowadays, which is crazy because I've only been doing it for, like, two years.

04:02 Yeah, honestly, your rise to power or fame has been very quick.

04:10 And it's such that, like, I don't remember what the results on the React, like, survey thing, but I remember you being on there. I was 55% of the people who answered the influencer questions said that they watched my videos.

04:28 Yeah, yeah. Weren't you, like, number one or something? Yeah, 2x the next highest. Yeah, yeah. It was insane. And, like, just a couple years ago, I was, like, 10% and in, like, 14th place. It's been insane.

04:42 Yeah, so, I mean, there are some people who are watching who are introverts and not really interested in becoming that at all. But there are certainly, and I want to actually talk to them here in a second, too. But I'm sure there are lots of people who would like to kind of make a name for themselves.

05:01 And I'm curious if you have any tips for those people who are trying to figure out how they can be recognized and have the work that they do be recognized. Absolutely. I talk a lot about this. I think there's one secret that made my channel successful as quickly as it was.

05:19 I was upset the videos I was making didn't exist already. COVID hit me really hard. I loved my lunch and dinner conversations with my coworkers at Twitch. And when COVID started, I lost that. I didn't get to nerd out about tech the way that we're going to throughout this time, I'm sure. I deeply missed those conversations.

05:37 I had engineers who are way smarter and more experienced than me that might not have been as interested in what just came out. So I would almost be the person going through Hacker News and Twitter, finding the cool new stuff going on in tech, and then talking about it at lunch with my coworkers that were much smarter than me.

05:53 And it was a really great way to bring my own value, which is the cool new things going on. And they bring their value, which was the decades plus of experience. And the conversations that came out of that were essential in helping me level up as quickly as I did when I was younger. When COVID hit, I lost that entirely.

06:10 I still kind of had the Slack channel where we would share things here and there, but it wasn't the same. And then when I quit Twitch, I lost it entirely because I was at startups where I was the most technical person and no one wanted to nerd out with me. My roommate was dying as I just info dumped every night about whatever I found interesting that week.

06:27 The reason my channel was successful is I didn't want to make it. I didn't want to be a YouTuber, but I wanted so desperately to have these nerdy conversations again, that it just kind of happened as a result of that. It wasn't a choice so much as a deep need to satisfy my desire to have these convos.

06:45 And when I went to YouTube looking for other people talking about tech, it's not that they weren't. It's that the majority of the well-produced content was for beginners. And the majority of the senior content was old tech talks from eight years ago that were poorly recorded. There wasn't really an in-between of really deep technical conversational stuff.

07:04 And that was what I wanted, so I started making videos like that because they weren't there. And it almost immediately took off because the thing I wanted, turns out, was wanted by millions of other people. Yeah, that makes tons of sense.

07:17 And it has a parallel to meetups as well, where I know a lot of experienced engineers don't really go to meetups because they find that the topics there are typically very beginner. And the attendees are like, I'm in a boot camp and my teacher told me to come, so here I am.

07:36 It's not that experienced engineers don't want to go to meetups. I think lots of them do.

07:45 It's just that they want to be in spaces where there are other people who have this level of understanding because we are at this level of experience and want to have those deeper conversations.

07:58 And this is, I think, why I personally enjoy conferences so much, because I can be around those types of individuals. Absolutely agree. And it's actually been an interesting, tough process for me with my channel where I see an opportunity to have 10x more viewership.

08:15 I just have to do it by niching up and making my content more accessible to beginners. And I don't want to do that because I don't watch those videos. I could do a five things I wish I knew when I started programming video, and it would probably do really well. But there's enough of that type of content already.

08:34 The thing that there wasn't enough of, the thing that I really wanted, was to nerd out about the details of the new SolidJS release or how does Quix hydration and resumability stuff actually work? Or why is my sequel still scaling better than Postgres most of the time?

08:49 These deeper, nerdy things that aren't necessarily useful to somebody in their first year of development are the bread and butter of what I do and like to talk about. And it shows in my numbers. To this day, over 80% of my viewership comes from people who are 25 or older.

09:03 I could change that, but I would lose the thing that I love about the channel, which is nerding out with people like you.

09:13 Yeah, I love it. And I think a really great takeaway there is to do the thing that you enjoy doing and find your people who enjoy that as well. And I think that the authenticity comes out naturally when you do that as well.

09:32 Absolutely agree. There's one part I will say that doing what you love isn't as important as doing the thing that you're upset doesn't exist right now. An example of that is the business I run right now, Upload Thing. We were originally building tools for creators, funny enough, alternatives to what we're using for this right now, Riverside.

09:50 We built ping.gg to make it easier to do live content collaborations. We won the space, but it just wasn't a particularly big space. And then Twitch went and cloned us. We're still slightly more popular. It's a whole thing. We're now focused on developer tools.

10:03 And the first tool we built was one that we thought was really fun, cool, and exciting that we wanted to build, but it wasn't one that necessarily everyone needed. We called it Webhook Thing. It was for managing and replaying webhooks locally. And it was super, super cool. We had a ton of fun building it. A bunch of the engineering behind it I actually covered in my ViteConf talk last year,

10:22 showcasing the crazy full-stack developer experience around hosting a CLI with a mini embedded Vite app. It was so fun, but it didn't hit at all. I was working on another side project for just managing assets for my YouTube channel, just dealing with thumbnail faces and stuff.

10:40 And the hardest part, as it always was, was getting S3 set up correctly. I'd been complaining about this for three years at the time. I look at my roommate. He looks at me. We say, is it time? And we begrudgingly go and make what is now Upload Thing, which is not something we wanted to build. It is miserable building an upload service in a file management solution.

10:59 It is not what we wanted to do, but it has taken off like nothing we've done before. Not because we hated or loved building it, but because the thing it solves was a problem that we had felt it wanted solved for so long that that got us through any humps and hurdles, and we were able to get something that resonated out relatively quickly.

11:17 Whether or not you love the thing helps with the longevity of sticking with it, but whether or not you care enough about the solution that you can't sleep at night because this thing doesn't exist and you want it to so badly. If that's a video, if that's an open source library, if that's a business, if that's a talk idea, if it's anything.

11:35 If you are genuinely upset that it doesn't exist, power through it. Even if it's not fun to build, that can be one of the most rewarding things you do with your life. That is awesome. It makes me think of something that I heard recently.

11:52 There's this podcast I listen to called Acquired that is just fabulous. Really interesting, deep dives on the history of various companies that we're all familiar with. I just finished listening to their part two on Microsoft.

12:06 One of them said something I thought was interesting, which is to just become addicted to a problem. You just focus in on that problem. That spoke to me really well because I think sometimes as engineers we can get addicted to a solution

12:25 where we're just like, wow, this is a really cool solution for this without realizing that it doesn't solve a problem that's interesting. We can create solutions and then look for problems that they solve sometimes just because it's fun to work on the solution.

12:42 It sounds like what you're recommending is just like, I hate that this doesn't exist. This is such a huge problem. We need a solution for this.

12:52 Then you go and find or build a really awesome solution and just focus so much on the problem that the solution you come up with is use case driven rather than just fun engineering problem to solve.

13:07 I love the distinction of obsessing over the problem versus obsessing over the solution. I'm absolutely stealing that. Thank you. You've already paid me back for the time I'm spending on this. Nice. Clip there. I love that. It's funny because I'm realizing now a bunch of why I get the pushback I get sometimes is because I don't obsess over solutions.

13:26 I might have a phase where I really like a solution, but then if I find something that better solves the problems that I care about, since I care more about the problem and the solution, I'll gladly hop solutions. I still get crap from when I moved from Prisma to Drizzle because I found that Drizzle was more performant for the specific types of things I wanted to do and required less overhead and tooling to work with.

13:46 It's not that Prisma is a bad tool so much as Drizzle is a smaller tool that gets out of my way a bit faster in my mission to solve the problem. If your obsession is the problem, not the solution, you end up changing solutions quite often. To some people, that looks like I'm just changing my mind every few days, but in reality, my focus has never shifted.

14:03 I want to solve these problems, be it making it easier to compose full stack applications, be it managing files, being more viable. A current obsession problem I have right now is image optimizations. It's crazy the state of image optimization and management.

14:19 I think Vercel has a really good product with Next Image, but obviously, it's not the cheapest thing in the world. As I've looked for alternatives, the current state of images and the average developer's understanding of them is just not where it needs to be. I'm now obsessed with this problem.

14:33 I don't even know how I'm going to solve it yet, but the idea that 70% to 90% of the images on the web are poorly optimized at best. Over 97% are still JPEGs and PNGs, which is what? How are we still using those as our web formats when we have multiple formats that are exponentially less data to be sent?

14:52 Over half of web traffic could be deleted if we were to just move to these better image formats, which is unbelievable to me. Things like this, I'm obsessed with. Yeah, yeah, wow. I look forward to optimize image thing or whatever.

15:09 Naming is hard, okay? Well, this is coming from the guy who made testing libraries. Phenomenal name, by the way. Yeah, that was actually Ryan Florence. He joked with me. He said, you should call it testing library, and so I did. I love it. Yeah, very cool.

15:26 You mentioned another problem. I can't remember the way you phrased it, but it made me think of React server components. Full stack composability? Yeah, that's what it was. Full stack composability.

15:41 So to get into that, a couple, like a year and a half ago, I think, I wrote a blog post on epicweb.dev about what I called full stack components.

15:51 And it was a pattern that I kind of come up with that allowed you to have your component UI right next to a remix loader that it served or even the action as well. That made it really easy to have that kind of co-location. And it was a while.

16:09 I think at the time I knew that there were some limitations with that. I can't remember if at the time I knew that React server components solved some of those problems, like the level of indirection and things.

16:25 So yeah, and it certainly wasn't the sort of thing that you could just npm install and now use my component and everything is available there. So I have also been thinking about this problem quite a bit. And I'm really super excited about what React server components can enable in solving this problem.

16:44 That said, do you want to kind of talk about the particular problem that you have experienced that makes React server components a really compelling solution? Man, how much time do you got? I can nerd out in every single direction about this for far too long.

17:01 The trials and tribulations we have went through trying to get server components to deliver the composability promise has been absurd. But the output and the result is incredible. It's the component moment again.

17:15 And it just feels special to realize that the way we have separated these things in our brain might be wrong. It's not that this new solution is guaranteed to be right.

17:26 But the arbitrary barriers we have built between these components and these parts in our head might not be as static and hard and rigid as we initially thought they were. And that's just a super exciting thing to me. So I can go down the path of what this means for development and how it compares to the original component and hooks changes.

17:44 I can go down the experience of trying to get these things working for our end users and developers. I can discuss how it's changed the way we build UploadThing fundamentally. I can go any of these paths. Let me know where you want to head.

17:56 I take it that UploadThing has a publish package that allows me to just import the component, stick it in my UI, and then it gives me this choose file button and magically it goes to UploadThing.

18:15 And I don't have to really do a whole lot. Can you describe a little bit of what is going on behind the scenes? Or maybe describe this component that I imagine exists and what is going on behind the scenes and how does RSC's React Server components enable what you're doing?

18:33 Absolutely. So something we went out of our way with UploadThing was to not have magic in the traditional sense. We didn't want to have things just magically behave in ways that didn't make obvious intuitive sense.

18:51 We went for intuition and clarity rather than magic, and I think it shows in the SDK and how you set it up. When you set up UploadThing in a project, the first thing you configure isn't the component. It's what we call the file router. It's a set of endpoints that you define that are the different ways a user can upload. You might have the profile picture upload endpoint.

19:10 You might have the post video endpoint. These are all part of your router object, and these are different keys in it. You might have image uploader colon, and then you use our helper function, just named F, to define what that can take. You specify this can take an image up to 4 megabytes.

19:28 And then you have to define a middleware function that authenticates the user because you have the request right there. So you have to do something with the user's request before you actually process the file as mandated with the actual SDK.

19:41 A problem we saw a lot of developers having and a lot of services online have is that they just blindly hand you a pre-signed post URL, and they don't even know if the file upload is complete because they rely on the user, after doing the upload, to run some JavaScript to then ping the server and say, hey, my upload is done.

19:57 And the result is there are lots of ghost files sitting on these random S3 buckets that developers don't know about. So we have an onUploadComplete function in our backend code that you run on your server that we notify you when the upload is done, regardless of what the user does on the client side. So you have the definition for what the user is allowed to upload.

20:16 You then have the middleware function for who is allowed to upload, attach metadata to whatever else you want there. And then we have the onUploadComplete, which guaranteed runs after the user has finished uploading the file, even if the user does something malicious in the process. And that simple 1, 2, 3 was something nobody else provided. And I'm amazed nobody else does to this day.

20:36 To be fair, it was really hard for us to set up on our side, but I'm super proud of the result. Once you have that configured, you kind of go into what I call TRPC mode, which was very inspired by TRPC. One of the lead maintainers from TRPC is one of our core employees now, Julius. Absolute legend. Oh, cool.

20:54 Full stack TypeScript and monorepo god. Single person who makes modern TypeScript monorepos actually function. Love him so much. He set us up with some really cool DX where you import the type definition from that router to define the components. And now when you actually use the upload button, the upload drops in, or any of the components or hooks we provide,

21:13 you have to give the name of the endpoint it's expected to hit. And if the name is wrong, type errors, you can command click and go to the back-end code for it. And now we can take advantage of that router definition. We can actually embed it in the app with a server component using some fun server-side data rendering stuff. Do I have a video about this?

21:31 I don't know if I do, but at me on Twitter if you're curious and I can nerd out about this in detail. But the TLDR is we're embedding a JSON blob in the page based on what types of uploads the site supports. And now all the components can see that. And as soon as you load the page, the component pops in immediately with a little bit of text underneath that says,

21:50 Upload image up to 4 megabytes. We're not having you put that in somewhere. You're just defining the endpoint and what users are allowed to upload. We then embed the data using server components, and now we can access that on a server or a client component because the page data is already embedded on the server-side dynamically. And the result is just a phenomenal experience.

22:09 Yeah, wow. So it sounds like there is like one area of my app where I'm going to configure the router. And then use that to kind of derive the nice TypeScript pieces that you have. That's an amazing DX.

22:26 And then I'm just rendering server components wherever. Or client components. The way we set this up is so that the components you render for the user to do the upload, it doesn't matter what type of component they are. Our specific goal was to make sure that the data was always there. So what the server components are enabling for us is the embedding of the data in the page.

22:45 Our main server component is a script tag that embeds a JSON blob that has the data the components need going forward. Oh, interesting. So that's how you make it work whether it's server or client components that people are using. Oh, fascinating. Yep. And that part is also optional. We made it work without that.

23:03 And the way that the file router works is you host that in an endpoint in your app. So you will dedicate slash API slash upload thing to your upload thing endpoints. And now all the components, if they have the data, they have the data. They're good to go. And if they don't, they can fetch from API slash upload thing to get the data. That must be a nice little loading state as you're waiting for it.

23:22 We wanted to make sure that the components work in every single environment in every single scenario, which was admittedly challenging because it meant we couldn't use a lot of the niceties of server components. But the benefit is we get the developer experience and the user experience expected from RSCs regardless of what environment you're working in.

23:38 Yeah, I think that is a good call because there are so many people who aren't using server components. They're not in an environment where they can use server components. And some people still don't see the light with why server components are so great, and they're just not interested in jumping into that.

23:55 Lots of people still want to just do client rendered apps, and that's a perfectly reasonable way to build a React application. There's a ceiling, and we could talk about that too. But, yeah, absolutely. I think that makes a ton of sense for your business.

24:09 I suppose the primary differences between the server and client components are the fact that the server component is going to be – well, I mean, you can even server render a client component.

24:22 So I'm just trying to distinguish in my mind why would I use a client component if I do support server components. What's the primary difference between these two options? The way I have phrased this for people is instead of server versus client component, I try to phrase client component as interactive component.

24:42 It's not always the case. There are other reasons you'd want a client component to ship JavaScript to the user, but a client component means that JavaScript is being shipped to the user. So if you do mount our component for upload thing, like the upload button, as a server component, it has children that are client components.

24:58 You can't use upload thing without a client component somewhere in the upload thing tree. Because the browser doesn't know how to process a file input and then post that with a pre-signed post to an endpoint. You can't do that without JavaScript code. So in order to tell the browser, hey, I need you to do these specific things in these specific ways,

25:16 you have to give it JavaScript, and that's what the client components enable. Server components allow you to do things only on the server, though, which is really powerful. If I want to access my database, if I want to authenticate a user, if I want to provide different embedded data based on user characteristics, all of these things can be done in a server component in a way that they cannot be done on client.

25:35 Traditionally, if you wanted to expose different data to a user, you'd have to define a different endpoint, authenticate the user, and then send them that data. With server components, that goes away. The composability and ability to just access the data you want where you want is magical. It's a huge part of why things like PHP were so cool,

25:53 because you could just query your database and render different HTML. You could do that with server components, but instead of just rendering different HTML, you can render different React components that might be server components or client components. It's so powerful. The demo that blew me away early was having a component that was like a tab component

26:12 where you have three different tabs and they all render different content. The example was it was three different tabs that were all different syntax highlighted code snippets. On the server, I could generate those components. I could mount them as props to the tab component. The tab component lived on the client side.

26:31 It was a client component, but I could pass it tab A, tab B, and tab C that were all server rendered. I could render the markup, render the syntax highlighting, and all of that on the server side and then pass these three components to the client, which doesn't have all the JavaScript for those. It only has the JavaScript for the tab selector component.

26:49 Now when I click between tabs A, B, and C on the client side, it switches between the three different conditions the server rendered for it, which is just magical. Nothing has done that specifically before. Traditionally, if you had client side rendering for that component, you wouldn't pass it three different HTML states.

27:06 You would pass it the data to render those three different states, and the client side would generate the HTML when you click the button. The idea of the server almost pre-generating the different states so the client can interface with them is something I think is genuinely new and really, really cool. Absolutely.

27:22 The level of composability between the client and the server is also something that nobody does, even still. In a PHP app, you would have, all right, let's render my tab's component thing. Oh, let's make sure we have the script tag for that thing.

27:39 Oh, I guess I'll probably just use React for that. Still, I need to worry about getting the JavaScript on the page for that. And then if you wanted to say, okay, well, I'm just going to pass the HTML for the contents of those, so I don't have to render those on the client.

27:52 Okay, you could make that work, but if any of the contents of those things needed to do any interactive thing, then you're going to need to send the script tags for each one of those interactive bits as well, and you have to manage all of that yourself. Whereas with React, it's just like import component, render component.

28:10 It's like the thing we've been doing for years, but the backing behind all of that enables us to do some awesome, awesome stuff. And it's all just the regular composability experience that we've had from React for the last decade. It's brilliant. It really is.

28:27 And if we go back to the days where React was introduced, previously we had been pretty fully committed to the model view controller way of building, where we had Rails, which was very heavily model view controller. And when we moved to the browser entirely with things like Angular, we kept the whole model view controller with us,

28:44 even though that was originally a model to take things on the server and then expose them to the user on the client. We took the whole thing and just threw it on the client as though that was a good idea, because we didn't know better at the time. And what React did was challenge that.

28:57 It was like, yo, those three sections we have and the two walls between them, that's kind of arbitrary. What if we let you decide where those arbitrary boundaries are? What if you can choose to put all the concerns in one place or spread them across the code base however you choose? It's not that React doesn't allow model view controller.

29:16 Believe me, I've seen some code bases that brute force model view controller into React. It's not good, but you can do it. That's kind of the beauty of React, is it doesn't tell you how to compose these things. It gives you the pieces to compose them however you want. And server components, or to go back to hooks actually first, hooks did the same thing with your state,

29:34 where components took the way we structured our UI and let us arbitrarily break them up how we choose. Hooks is the same for our state, where we can choose how much or how little of our state to bind where and how. We can have a piece of or we can have a hook, which is a piece of state management that can do everything from fetching data

29:53 to binding event listeners to activating AV devices. All these types of things can be state hooks that you can apply to any or many components instead of the component owning the state as just part of it. The state can be its own piece, its own building block. You can define yourself without even touching the component side,

30:11 and then you can bring that in where it makes sense to. And that was magical. That's actually when I went from, oh, this React thing's okay, to being the guy I am now. When I saw hooks as a functional program, I was like, oh, my God, I can compose state and UI and intermingle them. Server components are this now for the back end and the front end.

30:29 The realization that, like, the way to have your client get data from the server should be an API, be it OpenAPI spec or GraphQL. What if that was wrong and arbitrary? What if this idea that the web page is this pile of JavaScript that fetches from the server JSON blobs

30:46 then transform into whatever UI configurations the client happens to know about at the time? That's an arbitrary boundary that we just decided on a while ago and hasn't really been challenged since. We've had a little bit of playing with RPCs. I know I'm a big PRPC guy.

31:03 But the idea that maybe JSON isn't the right way to send data to the client all of the time, maybe the client having to have every single potential state of the UI embedded in it immediately is not the best. This is something big companies realized long ago.

31:20 If you look at code bases like Facebook or YouTube, they don't have all of the different types of posts or types of videos embedded in the app. The news feed for Facebook isn't 17 to 40 or however many posts there are, different components that are in the app waiting to get the JSON blob that says,

31:38 this is this type, so use this component on your device. Because if there's a 41st type of post, they can't wait for every single app to be updated. Most users at any given time are on an old version of an app. And if you want to ship something new, you can't wait for every single user to update.

31:55 You can't make sure every potential permutation of your UI exists on every single device and every single app that your users have. So the idea of server-driven UI has taken over in enterprise for a while now, where instead of the server saying, here's the JSON blob, fit this into the component where you think makes sense,

32:14 the server says, here's a rough idea of the structure for what this component should look like on your device. And then the application renders the structure rather than taking a structure it already has and stuffing the data in the right spots. This is necessary to ship at scale and to actually release new features to millions of users that are potentially on old devices.

32:33 And we've seen crazy things happen as a result. Are you familiar with the Project Lightspeed work on the Messenger app? Yeah. It's insane. For those who aren't familiar, the UI rendering layer and the UI organization layer for the Messenger app by Facebook is SQLite.

32:51 They use SQLite to define what UI goes where. And when they want to ship a UI change, they ship a SQL migration to your device. Because SQLite is cross-platform, it's really fast, it's really consistent, and it's structured. So they're able to define the way the UI should work in this single structure

33:09 and then share that across things without having to update the native binary. That's crazy, but it's awesome. It really is, and it makes me think of the cool stuff that Evan Bacon is doing over there at Expo. His demo, and he's going to be one of the folks I interview for this series too,

33:28 but his demo at ReactConf with server-driven UI at a native perspective, and he's also working on composing WebView stuff with native components.

33:43 It's just mind-boggling what this technology enables us to do. It's unbelievable. Every time I play with these modern solutions and server components, I'll just randomly have moments of, oh, yeah, that's a lot easier.

33:59 Like a dumb one I had, it wasn't that recent now, but one I think about a lot. On the upload thing dashboard, we have fancy little patterns on all of the cards for all the apps you have, so it's easier to distinguish between them. They're all generated based on the app ID. We just have a hash algorithm that picks one of them. I downloaded all of Hero Patterns.

34:16 If you're not familiar, Hero Patterns and Hero Icons are two projects from the Tailwind UI group that are just open-source piles of SVGs that are really useful, and the Hero Patterns SVGs are incredible. There are, I think, like 150 or so of them. It's a giant pile of SVGs.

34:35 We took all of them, like literally 100% of them, and threw them in a single TypeScript file. I think it's like 3,000 lines and multiple megabytes. It's a gigantic file, but because of server components, we can just have that file.

34:50 We can render those parts and just pass those pieces as props to the client-side components, and now none of that is felt by the user. We have a page that would have been multiple megabytes of JavaScript or TypeScript or would have required individually loading the different SVGs, which is a worse user experience.

35:07 We would have had to compromise somewhere there, but with server components, there's no compromise. We just have the one big file with all the SVGs. We render them, and it works, and no client-side penalty is felt. Those little moments add up, and the feeling is we can build fundamentally differently now.

35:24 It's the same feeling of hoisting a hook and realizing you can reuse it in five places, but we're doing that with our boundaries between the client and server side. Oh, man, yeah. You got my mind racing on that, too. Thinking about SVGs, I've thought about this quite a lot,

35:40 and your solution is so much better than what a lot of people are doing. The one thing that I was just thinking, how could we improve this further? One problem with inlining SVGs is that the content for those SVGs is going to be repeated

35:57 the number of times you have the SVG on the page, which normally is fine. But if we wanted to make it better, I'm thinking with the RSE payload, you could have one client component where the path to the client component is dynamic.

36:15 The server sends something dynamic, and so you have a query param of all the SVGs that should be included, and then the server generates a module at runtime. There are just some really, really interesting things that you can do

36:31 when you have this as a fundamental part of your technology. It's so cool, and I'm super excited to have this in a framework other than Next.js because I don't use Next. I'm looking forward to actually being able to deploy this in a production environment

36:49 and what it unlocks for us. It's going to be really cool. It's so cool. How do I word this point? Half lost it. Sorry about that. It was something about SVGs and loading them. I saw something online. I'm not sure if it was you who shared it.

37:09 I think it was Brooks, actually, who shared it around loading an SVG and then referencing it as an asset that's preloaded and how that doesn't currently work. That needs to be fixed. If you combine that with these things, it'll be so cool. I do actually think server components have the potential to meaningfully advance the web platform. There are things like out-of-order streaming,

37:28 so you can stream different parts of your UI in at different times, and that just gets resolved by React. That was a problem that took us, as a community, a decade to solve. That's just seamlessly built into React. We don't even notice. A lot of the power of server components comes from the lessons that Facebook and the React team have learned through Relay.

37:46 Server components are kind of taking the Relay compiler, which is an incredible piece of technology for generating the exact GraphQL endpoints needed and the exact queries necessary to fill your page with data, and now it's just accessible to everybody without having to adopt GraphQL or this really crazy paradigm that I used to joke the only way you're actually using Relay correctly

38:05 is if you work at Meta or you have two PhDs. The one exception was my friend Jane Wong, who now works at Meta, so she's no longer an exception. Those things were so hard. And also only worked for data. And as you just pointed out, now we can build that type of compiler that references the right things at the right time for anything.

38:24 It doesn't have to be data. It could be our SVGs now, and that's so cool. The thing that's holding us up is these browser standards now, but there's more incentive than ever for those browser standards to continue to improve, and I would expect a really bright future of all of these things going forward as we more and more realize the power of these pieces

38:42 and how cool and how flexible an experience we can build. Yeah, man, it's an exciting future. The more and more people on the boat, the better as well, because we just get more innovation,

38:56 and a lot of people talk about how React's true feature is the community, and that's sticky stuff, man. There are other frameworks out there that have arguably technically better implementations of different things and whatever it is, but it doesn't matter

39:14 because none of them have the size of the ecosystem and the number of people working on problems and innovating that React does, and that's been that way for a long time, and I expect it will continue to be that way for long in the future.

39:29 And huge credit to the React team as well for not just resting on what worked. Most people in that position would just sit on the things that are working and not innovate meaningfully. I've seen other communities doing this like Svelte going all in on runes, accepting that their way of doing state bindings was not composable enough and didn't work outside of Svelte files,

39:49 and if they wanted to have this rich ecosystem, they had to do something similar to what we have with hooks, or in Vue, the move to the composition API that angered a lot of Vue devs at the time but was absolutely the right call. I borrow visualizers that Evan Yu did all the time

40:04 that he used for describing the new composability API in the composition work in Vue, but the React team just keeps going. Like if they just had done components and sat on that, we would still be using React a lot today, but introducing hooks in late 2017, early 2018,

40:20 introducing all of the cool things we see now with server components, introducing the React compiler, all of these things are novel, and it's cool that they're not letting the success of the framework and the community block them from continuing to innovate. There will obviously be road bumps along the way, like we just saw with the suspense stuff,

40:39 but they also are holding up the React 19 release. There's a major React release that they have not put out yet because they saw that it hurt an admittedly very, very small percentage of React apps, but those were apps by some of the craziest diehard React fans because they were using suspense as it was given to them in the early state

40:58 to do crazy things the React team had never thought of, and when the React team accidentally broke it, they realized this is the most important part of the community. These are the people who care the most, and they've held the release now for what, like two to three months as a result of that. It should have come out right after ReactConf, and we still don't have it because they're fixing this problem.

41:17 React worked really hard both to continue innovating despite the reach and size of the community and to do what is right by the community leaders that are terrified of a lot of these types of changes, and I don't know if any other team in the history of software has done so much to challenge their community while also supporting them and pushing them forward.

41:35 Yeah, the React team has really just been epic in what they have accomplished, and the fact that they keep innovating is certainly commendable, and I just posted the other day, like, if you're a beginner web dev trying to get into web, the best thing you can learn is React

41:54 because it's by far the most jobs that are available there, and it continues to innovate and dominate like nothing else. I just think that it's special. It's really cool, and I love being a part of this community.

42:09 I saw this was a number that was dropped in the keynote for ReactConf. I don't remember the exact number. I think it was 50-ish percent, but we'll go with that. If I recall, it was 50% of new devs start learning with React. Like, that's the place they start. It's not HTML. It's not Python. It's not Scratch.

42:28 It's React, and I know that's terrifying. It's like, wait, you need to know the basics. You need to know the difference between JavaScript, HTML, CSS, and React, and I agree, but it's more important to feel like this is an achievable thing, that you can actually make something that works. Feeling good about what you're building is more important than understanding what you're building, especially early on,

42:47 and it's hard for us to remember what the first three to six months were like because that was so long ago. For me, it's been like 15-plus years since I was a new developer, and they need to feel good about what they're building. I almost gave up four-plus times as a dev. In fact, I did.

43:04 The reason I stuck with it is I wanted to play Minecraft with my friends, and I got really into server hosting and Java in order to do that. After failing as a web dev, a game dev, and all these other things multiple times throughout high school, the desire to have this one thing was so powerful that I pushed through these things I didn't understand or know. I was intimately familiar with Git and GNU Screen

43:22 before I knew what a class was, and that's just the nature of the problems I was trying to solve. The reason I like React as a starting point is it gives you that inertia really early. Even if you don't understand the pieces, you can see a completed puzzle and be really proud of it. The quicker you can have that feeling of pride and accomplishment,

43:40 the more likely you are to be successful with your career. I'm super 100% agree. Actually, it's beautiful because it brings us full circle with being obsessed with the problem instead of the solution. I love that you said that you don't have to understand what you're doing for it to be...

43:58 Ah, now I lost it. You don't have to understand the pieces of the puzzle to be proud of the puzzle being done. Yes. What new developer really understands what's going on even when they write an HTML tag? They don't, and that's fine. I 100% agree.

44:17 We need to just have really quick wins when we're getting started. The fact that people start with React, that doesn't bother me one bit. They'll fill in the gaps later, and that's part of what Epic React is all about. Even the first couple beginner-level workshops,

44:34 I have advanced, experienced React devs going through that and like, I'm filling in gaps. I didn't know we're there, and that's good. That's like ship stuff. You can come in and fill in the gaps later when you want to level up. I think we've been chatting a little bit over. Was there anything else that you wanted to talk about

44:51 that we didn't really get to today? I think we covered pretty much everything. My one last thing on the topic of driving yourself towards the things that you're proud of is you've got to be used to failing too. For anybody who's watching these that's trying to level up as a dev, you're going to run into things that are hard. That's why we're paid what we're paid.

45:10 That's why we do what we do, and that's why so many devs are as passionate as they are. Not because it's just super fun and everyone's going to love programming, but it's kind of the rest were filtered out because this is a hard job. There are going to be parts where you feel like you have no idea what's going on and you're bashing your head against the wall. A huge part of why it's important to do things you care about

45:28 is that you'll push through those things earlier. I'm really lucky that I built this resilience as a skateboarder. You don't learn a new skate trick by going to class and sitting there for eight hours as they tell you about the inner workings of the wood cranes used in skateboards. You get better at skateboarding by going outside and hitting the ground a whole bunch until all of a sudden you're riding away.

45:47 Software dev is no different from that. You have to be willing to, as I put it, to be a little frank, you have to be willing to eat some shit. You have to be willing to get hurt a bit and feel bad and feel dumb. We all do. Every day when I'm working on software stuff, I feel stupid about something that I'm doing. If you're feeling dumb

46:06 as you're learning these things and progressing, that's a good sign. If you ever don't feel like you're a little outside of your comfort zone, that means you're not pushing yourself and you're not challenging yourself. And if it's hard, try your best to find something you care about more than code, more than money, more than those other things. As silly as it was for me, it was Minecraft and playing it with my friends.

46:25 And that was enough to push me through these really hard things. As a 16-year-old learning how to host servers and deal with SSH, you can get through it if you care enough about the thing on the other side. And I don't think that can be money. I don't think that can be a vague desire to be a programmer. If you have something you want to build, something you really want to create, it can be a YouTube video,

46:43 it can be an open-source package, it could be a company, it could be a side project where you make a clone of Twitter for dogs, whatever it is, if you care enough, you're so much more likely to push through those hard parts and actually come out the other end successful. Well said, Theo. Thank you. I really appreciate that. I appreciate your time.

47:01 And what's the best way for people to connect with you? You mentioned, like, following you up on Twitter. Is there anywhere else that people want to keep up with what you're doing? Twitter's the best place if you want to get my attention for things. If you want to just see what I'm up to and making, check out my YouTube, t3.gg over there.

47:19 I post almost effectively every day nowadays talking all about software dev stuff. If you're interested in more niche, like creator stuff, tech stuff, like the state of Apple, those types of things, my second channel, named Theo Rants, is actually blowing up right now. It might overtake my main channel in the near future just talking about Adobe drama or the weird things Apple is doing

47:37 with legislation in the EU. So if you're nerdy about those things, check that out, too. Very cool. Thank you so much, Theo. And thanks, everybody, for watching. We'll see you all in the next one. Peace, y'all.