The future of React with Theo Browne
===

[00:00:00] 

Hi there, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, ever tracking, and product analytics. Try it for free at logrocket. com today. My name is Paul and joined with us is Theo Brown. He is the second best TypeScript YouTuber out there, first and foremost, but he's also the founder of ping.

gg, web dev, content creator, speaker, and enthusiast all around. He's here to talk about the future Of react. What a lofty topic. We're excited to get into it. Welcome Theo.

Welcome. Welcome. Thanks for having me.

So you gave a talk recently, which is called the future of react is us. And it felt like a very motivational talk. It touched on a lot of maybe emotions that people might've felt when they were listening to that talk. Cause it wasn't purely technical getting into, like the history react and where we are now and where we're heading.

Let's start at the beginning and, what is the current state of React, just to orient [00:01:00] ourselves. When you opened up the talk, you were like here's where we are. Where are we, Theo?

It depends on who the we is, honestly, because there's we the enthusiasts who listen to a podcast like this, who are playing with all the new things, who are trying out the stuff. People like me who have been shipping app routers since the beginning of the year and using all this new tech. But there's also the average react developer.

Who's a person that hasn't actually ever emitted a react application. Like they've never run create react app or create next app. They learned react because at their job, there was a react code base and they wanted to contribute to it. So for that developer, where they're at is very different from where the enthusiasts are, but I do expect that gap to start to close over time.

So I'm curious, like who are you specifically referring to in the we in this?

I would say that we're referring to the enthusiast. I felt like the future React and the way that you were talking about it in that speech you were giving was very much aimed at this torch that we need to hold and carry forward with us. And that audience is definitely the enthusiast. So taking that [00:02:00] perspective.

Absolutely. So I think the spot we're in right now is. Similar, we're in between where like the AngularJS to Angular move was and the move to hooks where none of our previous ways of doing things are broken. Like you can take code from an ancient react app. I actually found source code from like the blog from 2012 on the official react blog and ran it on the server with the new server component model without issue.

The challenging piece that's put us in this weird spot is that it's The new React model and these new awesome things we're all so excited about can't be adopted from the bottom up the way we could with something like hooks. Like when I was at Twitch, when we were building using React for everything on the web, hooks happened.

We updated the React version in the application. It didn't really break anything that I can recall. And then any team that wanted could start adopting hooks and components that were all the way at the bottom of the tree. They didn't have to consult with other teams, get [00:03:00] approval, do anything. They just use state instead of using a class component.

That isn't an option with the new react model with server components. So that's put us as a community in a weird spot where this really exciting new thing. Isn't something we can easily start playing with at our jobs just yet, but we haven't even started talking about what that new thing is yet. So just wanted to give the context of where we are as a community right now.

But that's not necessarily a bad thing, a bad spot to be in. It's just, it's a different type of spot, you would say, right?

Yeah, I think it's worse than previous new things in react in the sense that. With hooks, it was so easy for one person at your company to be enthusiastic about it and get them adopted in a really meaningful way just by using them in some components and slowly people seeing the benefit of the pattern.

It's much harder to get the necessary buy in to start using server components at your job. And that's the concern I have that makes this new spot. Not bad, but not as smooth as where we were with previous major innovations in the React [00:04:00] ecosystem.

I mean, You mentioned the elephant in the room here it's server components. That's the spot and pinnacle that we're sitting on right now. And so you're mentioning like getting into this new paradigm. You can't go top down necessarily. You really have to change the way that you're approaching the app.

And in, in your talk, you mentioned a few times that react in general, it asks a lot from us, it asks a lot from developers, can you explain a little bit about what you mean? in that phrase particularly and how it relates to the challenges with adopting server components.

Yeah, so from its genesis, React challenged a lot of what we consider normal as developers, especially web developers. At the time React was introduced, the MVC model had fully taken over the browser, and we were really committed to it with frameworks like Angular, where you kept your state, your model, and your template.

Entirely separate from each other and would build increasingly complex ways to interact between those three layers react said, Why are we cutting these layers up? Why don't [00:05:00] we write the code that describes what the user sees and how they behave with it starting from the base unit of a component rather than the base unit of a template and that shift.

Fundamentally change the direction of react as a whole and react that shift fundamentally change the direction of the web as a whole and it's taken a while for us to as a community really learn those lessons and also teach them and now we're seeing things like swift ui and the apple ecosystem that clearly learned a lot of those same lessons that react was trying to push We saw things like JSX get an insane amount of pushback when people first saw them.

Like, why would you ever put your JavaScript? We do it the opposite way. That's wrong. And slowly we've seen more and more frameworks either adopt JSX or things like it in order to have those same benefits, the co location of your scripting with your markup, that is what makes react special. It challenges us to think with different boundaries and break the.

Mold of what [00:06:00] each piece is supposed to do. And instead think about what's the simplest way to deliver the right solution to our users. But now as engineers, we don't just have to change how we're thinking. We also have to change how we're communicating in order to convince others of these things. And with react, that was hard enough convincing a developer who had been working on the web for 15 years, that NBC might not be the best method.

And we could write this crazy new JavaScript syntax to build web components. The server component model is even more challenging in the sense that it's entirely rejected the existing boundary between server and client and is proposing a new flexible one for us to use as we please. And that again is incredibly powerful and results in us being able to make applications better and simpler, but convincing others of that and picking up on the model even in the first place is so challenging compared to something that's just the way it always worked.

Yeah, I totally hear you there. And server components, they're not necessarily the [00:07:00] end all be all to how we're gonna run with this idea of, hey, the server's important. And you mentioned specifically, like, There are growing pains, there were growing pains and there's growing pains that teams are still dealing with and maybe mentioning and calling out some of those and explaining how they weren't a waste of time, but they're, they were fundamental building blocks to where we became one only feel cathartic, but useful and understanding like this positive direction we're going.

And so could you like mentioned some of those growing pains and how we came to where we are specifically within the scope of server components.

Of course. React was built to solve the, at the time, somewhat simple problem of, Hey, I have this data. I have an interactive client and I want to render markup that is interactive and changes when users do different things. Maybe you click a button to leave a comment and it fetches new API data and renders something different in line.

React solved that really well, but as we started using it more and more, the amount of JavaScript that was necessary to Render the right thing on the client in the first place increased [00:08:00] in its complexity, and the need for some type of server rendering became apparent. The idea of server rendering in the original React form was that we'd run the React code on the server once to generate a default HTML state.

Then the client would get that HTML, it would get the JavaScript necessary, and it would do a thing called hydration, which was Effectively running that same react code again on the client in order to make sure that the JavaScript understanding of the HTML and the actual HTML in your browser were the same.

It's also introduced the concept of hydration errors, but that's a whole separate rant. Gatsby and Next. js were the first frameworks to really push this idea of pre rendering the HTML, so you wouldn't get a blank page when you first went to a URL. Before we had server rendering, you'd go to a page, it would be entirely blank, white, or just have a little bit of templating that you hand wrote in HTML.

That would load the JavaScript that would then load the react code that would then go to a bunch of API fetches and do whatever else it needs. And then finally, like five steps and seven waterfalls later, you're seeing the [00:09:00] content you're supposed to see on the page. And every single element on the page has to have JavaScript that runs both on the server and on the client.

So if you have a top nav that's entirely static, but it's written in react code. That JavaScript, even if it never runs again or changes again, still gets shipped to the client as something they have to deal with in their JavaScript virtual machine and in their JavaScript runtime on their device. And it just takes up additional RAM, takes up additional bandwidth, takes up additional mental overhead for us as the developers building and maintaining these things.

And you're effectively taking the single giant React app that keeps getting bigger and running it in two places so that you could have HTML show up slightly faster. But the amount of time it takes to make that HTML interactive, the amount of time it takes to render your next update, the amount of time it takes to make that experience good, keeps going up as the application gets bigger.

And that was the challenge that even the new server, even the previous server rendering models couldn't really [00:10:00] solve. We couldn't just create the right HTML and expect the browser to know what to do with it. And that's why server components were introduced. The concept was. Maybe we shouldn't be sending all of the JavaScript for everything ever to the client, and maybe the client shouldn't be expected to receive JSON and then transform that into the right data on the client.

What if, for the things that only needed to be static, the server didn't send JavaScript, instead it just sent the HTML, and now the only parts that need JavaScript are the ones that change and that you interact with? Or, even crazier, what if the parts that changed only changed when an API call happened?

Why does that API have to send JSON that the client then parses and turns into HTML? Why can't the API just send the new HTML to the client? And this is what makes the new server component model so strong. It's a hybrid of like the OG classic, like submit a form and get back. A new HTML page and something like what Remix does with their loaders and action patterns in like smart code splitting, but [00:11:00] with a much more granular nature.

And I actually just saw a tweet from Ryan Florence from the Remix team that really like pushes the sentiment. It feels like what server components do differently aren't just. like reactor server rendering. It's like transit protocols where we moved from rest to graph QL, especially for big applications to standardize how our APIs were interfaced with on the client.

And more importantly, Make the right API for our clients server components are the next step in that direction where instead of sending json We're sending HTML because that's more often than not the thing that the client actually needs and it makes Managing complexity in your applications way simpler than I ever would have imagined.

It almost feels like we're on the same path of bringing components into the UI. Okay. We're applying the component layer to the API now. at that same granular level. And you don't even need to think about it. You already know how a component works semantically, right?

Yes it's one of the coolest parts of this [00:12:00] model. Is that like Something I've been saying a lot is NPM installable infrastructure, because with components being so modular and composable, you've always had the ability to make a reusable piece that was a generic. Like, there's companies like Clark that give you a React component that's your entire off layer.

And now you can NPM install their. Off components in pretty trivially build a good authentication system in your application with what we're doing for upload thing at ping, which is an easier way to do file uploads. Next JS is you're installing a full back end service that just runs in an API end point with server components with client experience with user uploads all authenticated through your service and you just NPM install our package to set that all up.

Since components in the component mindset is so modular, carrying that over to things that aren't just like UI, but more complex infrastructure things is more trivial than ever with this new model. And that's what's so exciting is we're no longer just thinking about how does this button work when the user clicks it, we're [00:13:00] thinking about how do we get this component there in the first place?

How do we interface with other systems and services? It it forces us all to be a little bit more full stack, but in doing such makes us much more aware of our component life cycles and makes it easier to write good software.

The idea that everybody's a full stack can definitely scare some people maybe at first sight. And that's the other side of the coin that I want to get into. Before we do that, I just want to remind our listeners that this podcast is brought to you by LogRocket. So if you're trying to test out server components, or you're making a new feature, you can spend less time debugging and figuring out what's going on in your console, if you've got logs and stuff like that.

And you can spend more time building a good app. So go to logrocket. com, you can check it out, and supercharge your development today. Hopping onto the other side of the coin of good things, there's always, opposition to new features and stuff.

And in this example, one might argue, Oh, well now I have to be a full stack dev. Arguably servers are [00:14:00] hard. That's the line that you used in your talk. Servers are hard and it could affect adoption. And it could affect the way that this arm of how we develop changes over the next five years or whatever it be.

Could you go into some detail about what you mean by servers are hard and how you think it might shape the future of React server components?

Absolutely. I don't specifically remember the context of why I said it in that talk, but in a general sense, servers are a layer of complexity that needs to be orchestrated. The client tends to be isolated in the sense that it lives in the browser, in a browser tab, and you don't have to necessarily worry about what it interfaces with other than your API layer.

Once you have a server, it becomes less about the specific line of code and what it does, and more about the relationship that server has with other things like your database, like other servers, like your Redis cluster, like your client itself and the API layer for that, like the mobile app and how it expects things to behave differently.[00:15:00] 

Servers are complex in the sense that if you're bringing in a server, you have a complex relationship you're managing almost inherently. And this is again, what makes react server components so interesting is it's trying to, rather than like give you this explicit boundary that exists, always has something like an API layer.

It's encouraging you to take that boundary almost wheel it like a stick and move it where it fits best for the applications that you're building, which. Takes a little bit more thought, but also results in much simpler, more digestible. They know how to put other than like problem solution stacks where when I'm thinking about a feature I'm adding or a problem I'm solving, there might be more pieces I can pick from total, but the amount of pieces and more importantly, the complexity of each of those pieces feels smaller than ever.

And I think when people get overwhelmed by servers, they're overwhelmed with the amount of things rather than the complexity of those things. And as a. web dev that [00:16:00] does a lot of react. I can promise you there's more complexity and use effect than in almost all the new primitives combined and in most of server architecture as a whole.

Yes, there's a lot of pieces and yes, we have to think about those and be more conscious of them, but those pieces are inherently less complex than a lot of the things we deal with. And I think a lot of the fear I see is coming from developers who every new piece was more complex than the one before. So every time things were added, their lives inherently got harder with server stuff, especially with new like server practices like serverless and Lambda functions and edge functions and like all these new awesome primitives.

It's become easier than ever to build a backend. You understand with sure, seven to however many parts, but those parts are much easier to digest too.

As developers, I typically feel that one of the things you touched on is possibilities. It's if you hop into a new design software for the first time.

And you try to design, so it's like, Oh, wow, what tool do I choose? And that [00:17:00] paralysis can be debilitating, extremely debilitating. And it sounds like what you're telling me right now is like, we have these pieces that are more well defined than ever before. There's guardrails for you as maybe you're coming new into the ecosystem.

And you're like, I don't even know the history of forms and like about page reloads. Would you say that this push marches in that direction via the componentization of these? front end and back end relationships. 

Absolutely. And. I'm going to pivot this very slightly because my experience with server components was a huge part of why I've changed my own tune on this. The thing that was the most overwhelming for me with server components compared to the previous React model and other things I built with was how in your face the failures in like using it wrong felt compared to other things.

Like when you screw up a use effect, you might not notice until months later when in production it's firing erroneously hundreds upon hundreds of times per user when you thought it would only ever fire once because it hit some weird edge case where the diff isn't being tracked correctly with. The server component model.[00:18:00] 

If you're doing something wrong, the page doesn't render or you get an error immediately. So if you're using the wrong piece for the thing you're trying to do, it feels like it slaps you in the hand a lot quicker, rather than waiting and doing it later. And that's been monumental for us. We might run into bugs while we're developing like 20 percent more.

I would guesstimate, especially when we were first getting started with the new patterns, but the bug hits you in dev almost immediately rather than hitting you with some alert on log rocket months later. And it makes it much more obvious when you're using the wrong piece for the job. Like if you're doing something in a server component, that should be a client component.

You click the button on the page and just won't do anything, or you'll get a compile error that says you can't bind an on click to something that isn't running on the client. And if you are trying to fetch server data inside of a client component, it's going to yell at you and say, Hey, you can't run Prisma inside of the client.

And that makes the behaviors in the failure cases feel so much more obvious when they happen. It's [00:19:00] much easier to learn this model by using it versus previous react models. And especially again with hooks and things like use effect. If you were a javascript dev learning react, playing with that stuff without going through the incredible react documentation.

Good luck, have fun. It's super unintuitive. With the new model, simple things like just having async server components where you can await a database call and then return HTML makes it much easier to do something obvious, read it, understand what it does, and if the obvious thing doesn't work, you get an error that tells you why for the first time ever in this ecosystem.

that sounds super refreshing. Coming to react for the first time and the errors where you even find the error can feel difficult. So having it thrown at you, it could be a great thing.

absolutely agree. I think error messaging and like the quality of the error page that comes up when something goes wrong in your dev experience is essential. And it's actually one of those things I think Rails did much better than the JavaScript ecosystem for a while, just like a good error [00:20:00] page that says what went wrong.

And while the actual quality of those errors and the fanciness of that page are still getting there, especially in the new Next. js stuff. The speed at which you get the feedback that, hey, something isn't right, that's what's impressed me the most is I don't feel like I hold it as I don't feel like I hold things wrong anywhere near as long as I used to with previous solutions.

Now, on the tail end of this conversation, where we are in react and where we're heading, there's this theme that you expressed Theo of like, we're learning from react. That's great. React is always learning from us, and React always needs our help, and I felt like that message, it was, it conveyed a sense of urgency with us as power users of React, and maybe if we could step into your opinions about that, and how you see the onus on that.

Thanks. also be on us as users, not just consumers of the product.

Absolutely. I was actually really surprised when I started talking more to the core react team. [00:21:00] The time I don't know if this has changed, but when I was talking with them about a year or so ago, there was a very clear sentiment that they felt like they had better insight on react native devs than react devs because react native devs due to the nature of the platform being so dependent on specific native bindings and.

The teams being so collaborative with people from Microsoft, Amazon and many other companies, they felt like they better understood what react native developers needed, what they were struggling with and how to push that ecosystem forward. They've never felt like they had that same level of depth and closeness with the react web community though.

And they were surprised the specific way it was put to me was. The people can reach out to us, but it feels like react web devs don't know that we don't know how to tell them. And the result was most of the feedback they were collecting was through random GitHub issues and Dan Abramov on Twitter.

They're really trying to change that. They're going to events. They're talking to developers. They're reaching out to people like me to get my thoughts on things. They're [00:22:00] really working hard to understand what is and isn't working for us and what solutions we're choosing to use on the stuff that we're building.

And I really think server components are. A beautiful example of them doing that, where they looked at stuff like what Remix was doing. They looked at stuff like what YouTube was doing with their server rendering stuff. They even looked internally at Facebook to see how they were handling complex things like the newsfeed.

And the newsfeed is such an interesting problem because if a team wants to introduce a new type of post on Facebook, but half your mobile users are on a version of the app from half a year ago or longer, you can't update the native code that renders those posts. You can't necessarily even rely on the web app to have the right JavaScript that they need for it.

So the angle they took was figuring out how the server can define the UI in the application such that the application doesn't have to be on a specific version to render it correctly. And they tried all sorts of crazy solutions with this around their custom PHP language called Pack, as well as [00:23:00] building crazy things on mobile, including React Native itself.

The goal with server components was to take all of these learnings from both the community and from internally at Facebook meta to build a solution. That felt native to both the web platform and to react itself and especially once you look at stuff like remix and how they admittedly had to do complex things to handle stuff like passing a promise from the server to the client and seeing react say Oh, that is a really powerful paradigm.

What if react itself did that? What if instead of passing a promise to the client? the component itself could be a promise that passes HTML to the client instead. And these lessons really show in the new model, even just the way they communicate things and how Dan's changed his framing on like, just calling or retake on that one, even just the framing and how Dan talks about these things on Twitter.

I know he's intentionally made tweets that were a little bit spicier in hopes that I could use those for marketing materials. And [00:24:00] points in my own videos. He made a tweet that was never write another API focused on how the server component model lets you stop returning Jason all the time. And I was able to screenshot that, use it as a thumbnail for a video and have it glow up communicating the same message they're trying to this back and forth is something I've never felt before in the react ecosystem where the influential developers and users, the power users who are excited to try new things in the react team itself.

We've built this flywheel of feedback, encouragement. engagement bait and overall hype around the problems we had and how these new solutions solve them,

And you feel like there, there's a onus on us as a developer community to push that envelope and continue this march, because we're receiving benefits of the framework. And do you think, like, everybody can do if they're not using server components today, for example, to Slowly [00:25:00] indoctrinate and spread the knowledge about the gra, the greener grass on the other side.

build something with it can be a small side project. It can be a one off app internally. I know when I was at Twitch, we had an internal safety tool that was used for reviewing reports and managing like band users. And I got to experiment there with all sorts of new tech. Cause I was the front end lead, even though I was a, like a just barely above junior engineer.

They let me try all sorts of new things and play with technologies and build a solution there because the splash radius for damage was much, much smaller. And we were able to try much, much riskier stuff as a result. And a lot of the things we learned. Just didn't work great. Well, all the things we tried and learned worked really well.

And we brought them back to the core site and ship them to millions upon millions of users and finding those opportunities to try out new stuff is really important. Going to slightly tangent to like Theo, the manager brain. So I have a lot of content where I try to talk about the importance for [00:26:00] technical leaders.

Not just the like influencer sense, but the person at the company that manages engineers, or at the very least inspires them sense. It's so important to. Maintain energy on your teams, especially if your goal is maintaining inertia and building great product. Having a team that's excited to work and do new things and build awesome stuff is so important.

And the vast majority of developers get really hyped when something clicks for them or a solution works and they weren't sure if it was going to, and building those opportunities as a leader for people to try new things and Experiment with these new ideas, even if they fail is such a good opportunity to both build trust with these engineers and build hype with your engineering culture.

It always breaks my heart to see how many companies don't take advantage of this inherent baked in method to get engineers hyped and build awesome things. Just give them the opportunities to screw up, do things wrong, and you'll be amazed at what the correct solution looks like [00:27:00] when it eventually happens.

And to close this out, Theo, I'd love to know what you wanna see from React in the near future. Maybe something's planned and you're looking forward to it, or it's not planned and you're like, they should really consider this. What's on your mind? 

So there's a biggest missing piece and a biggest potential direction. So for me, the biggest missing piece right now is some way to handle pagination in infinite data, so to speak, like getting an infinite scroll working where I'm scrolling down the page. And once I hit a certain threshold. More components show up underneath it, making a pattern that works well for that from the server to the client that isn't just an infinite query.

Jason blob coming in is really challenging. And I haven't seen a particularly compelling solution to this problem yet. To be fair, I haven't seen many compelling solutions outside of server components. Pagination and infinite queries and infinite scroll are all hard problems to solve. So excited for someone to figure that out either at the react core team or externally.

The [00:28:00] missing piece that I'm almost certain will be solved in the future that I'm just genuinely really hyped about is the idea of partial static cached HTML right now. If you have an API that is complex, maybe the server takes a bit to spin up because it's a lambda with a bunch of stuff in it, or the data you're fetching takes a while to come back from the database.

You can cash the Jason that gets spit out and then fetch that Jason and use it to do things, but you can't cash the component that comes out of that instead. So if I had an endpoint that was really slow and I'm using that to render Let's say the number of comments on a blog post, I don't need to refetch that data every single time.

And even if I do cache that fetch, I don't have a reliable way to bust it. What I want is the ability to cache parts of my HTML almost the same way we used to where we have the HTML template for a page that was handwritten and then React would take over the contents. I would love for react to be able to [00:29:00] save that static shell the outer layer before any suspense happens in your react app cache the actual HTML.

So I could send that from a CDN instead of from a traditional server, get a first response to the user instantaneously and then have react start streaming in the responses from there. We're very close right now. If you use the. edge runtime stuff. Even if you're not using edge locations, you can get a response to users in milliseconds and you can have a good experience getting the rest of the data from there.

I have a video coming out soon called my website is airplane proof, where I tried out my website on an airplane when I was flying to Portland to record some stuff with Jason Langstarff.

And I didn't expect the upload thing website to be particularly performant because we didn't put any effort into making it a good experience with low or slow internet connections and bandwidth. And the site was super snappy and genuinely really pleasant to use just from using the new primitives and anything that makes those defaults snappier while also keeping a simple mental model for us as developers [00:30:00] is really exciting and the thought of not having to use a custom runtime just to get that first response slightly faster instead having that be on a CDN.

At that point, I don't care what's doing the compute. It could be a 10 second cold start on the Lambda. As long as the user gets something good, where I can control a nice loading state, and the rest all comes in through a single web request. The amount of weird problems that I've been complaining about for years, I don't really care about anymore is absurd.

Like I think React will be the ultimate killer of the cold start war, which is something I never would have expected,

React will be the killer of the cold start war. That is a cool statement to close this podcast out with. So thanks for that, Theo.

of course.

Well, it's been a pleasure kind of talking about where we are with react, where we're going. And if you want to check out Theo's talk, you can go to, it was react a thon, correct?

a thon 2023, the future of react is us. If you search future of react Theo on YouTube, you'll find [00:31:00] that as well as my reaction video to me reacting to my own talk. So

Awesome. And of course people can find you on YouTube and on Twitter. What's the handle?

t3. gg spelt out D O T G G on everything other than Twitch where I just have Theo as my username.

Awesome. Well, thanks again, Theo. It's been a pleasure.

Of course. Thank you so much.