Your React questions answered
===

Emily: [00:00:00] welcome back to Pod Rocket, a web development podcast from Log Rocket. Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free@logrocket.com. I'm Emily producer for Pod Rocket, and today we're answering your questions about React.

Last month we asked you to send in what you were struggling with when it came to using React and if you had any questions about the evolution of React. So we're taking time today to talk to our panel of experts to answer those questions. And before we get into it, let me introduce you to those panelists.

First, we have sh day person returning to Pod Rocket. She's a senior software engineer at Netflix, educator for TypeScript and JavaScript. And speaker, . Welcome back SH day.

Shaundai: Thanks, Emily. It's great to be here.

Emily: Next we have Ben Holmes, software developer for Astro c e o of whiteboards and content creator also coming back on the pod after a little while. I think. Welcome back Ben.

Ben: [00:01:00] Yeah. Thanks for having me as always.

Emily: And then finally, we have our Pod Rocket host rounding out the panel. Noel Mincha lead software engineer here at Log Rocket High. As always, Noel.

Noel: Hey, how's it going?

Emily: Great. All right, so let's just jump into it. We got a good amount of questions. First let me start with Johann. Johann asked One thing that they struggle with is using fetch based on user interaction.

Could the panel share their best pattern for making a fetch request that sets state or fills a form that is. Fired only when the state of a text field has become valid, like an email or social security number.

Shaundai: I think that when I picture what Johann you might be trying to do, I'm imagining that you have an input and the user is typing their email address or their social security number into an input like an H T M L input or some custom input that you might have [00:02:00] from your styling library or something, right?

Or your component library. What I would do is I would put maybe an on key down or an on click to measure the clicks or subscribe to the click actions and take those clicks and then put the validation on that actual input. Inside the function that you connect with your on key down or your on click, put a prevent default so that you're not capturing every single click or like a de bounce or something like that.

So you're not capturing every click or running the function on every click, but except that event and the value of that event, there's automatic props that are included in the inputs that give you the value that's inputted inside that function check. The validity of it. Is the email valid or is the social security number valid?

Then if it is valid, then you can run that data effecting function based on the validity. So if it's not valid, [00:03:00] you won't run that function at all. You don't need a use effect because we're already subscribing to the changes on key down or on click, and then only run that function, which should be abstracted into a separate.

Function, maybe as a callback or however you wanna do it. And then only run that function. One, the value is going to be valid. So that way you aren't running the data fetch. Every single time. And you can run that function every single because it's de bounced. So it's gonna be pretty performant.

You're only gonna run that function every couple of clicks or every couple of seconds. However you set that up and then you have that data fetching that's subscribed to the validity of whatever the input is.

Ben: Forms are annoying because they're the, yeah I have many thoughts about forms because people are flip flopping on best practices there all the time. Right now, you might have seen things that you want to validate it all on the server and bring it back down [00:04:00] using something like a form data submission, or you need to validate it while you're typing.

It sounds like you need something while you're typing. You can't wait for the person to submit the form before you can go fetch the data. So for that I totally agree. You probably want to use an event handler always bias towards events instead of effects because that way you can actually make sure it's a one-to-one, that a user event is triggering it and you're not doing an effect over something that shouldn't be triggering it or is doing something by accident.

Also try to reach for Debo hooks and other things like that because you don't want to be firing your API on every input if you're using on change. In React or on input everywhere else, so you can reach for hooks for that. If you're using React, use dbo as a pretty common library that I reach for.

Just throttle it a little bit to 300 milliseconds and yeah, make sure you're not hammering your a p i too much, but otherwise just use events and that should work.

Noel: Yeah, I feel like the only thing that I will add is, there's a little bit of nuance here, like if your validation on the client is really fast. You don't necessarily [00:05:00] need to be de bouncing the call to the client side validation if you know that the fetch call , is only gonna happen when you are in a valid state, then like you just need to make sure that works there.

But I'm just thinking yeah, like social security number, you can run that validation client side if you're doing clients of validation like pretty quick. But then if you like, are waiting to fire until you get valid state, that's fine. , I guess it's, probably somewhat contextual, like depending on what you're doing, like address lookup, stuff like that, where you're required on the result of the fetch call for validation , should be implemented slightly differently than if it's like a simple client side validator that then makes a network request.

Yeah, just keep in mind that those are slightly different use cases.

Emily: Great advice. I wanna pivot over to react server components. We got a couple questions about them. Victor asked what are React server components and how will they improve the development of full Stack React applications? Pretty broad, but I think a lot of people are interested in React server components right now.

So if we could get a base layer of what they are and then how developers can implement them.

Ben: [00:06:00] Yeah, I've been researching this for a while. It was actually on a server components panel a little bit ago because everyone outside of next JS or inside of next Js, are trying to piece together like. How does this change reacts architecture, and do you need Xjs to use it and will there be a future where you don't need to use it?

But high level React server components are meant to be this, bringing things back to server fetching, something that you run into when you're doing server side rendering with React, which is a pretty common pattern. If you're using next remix, any of the popular frameworks is every component's gonna run on the server and on the client.

So you have to have smart implications of, am I running on the server right now? Am I running on the client? I need to assume my code is gonna ship both places, which can cause a lot of, you know, issues leaking a p i, keys, things like that. And it also implies that you're shipping a client bundle that's going to do all these fetch calls.

So there's a cost to that where you need to prevent default and ship client side logic for stuff like [00:07:00] Apollo, which can be very large client side bundles. So server components are meant to be a server only option for React, where you can write components that we'll only run on the server. You're not leaking anything to the client, you're not shipping any bundles unnecessarily, and you can.

Use Async weight to write, fetch calls, or write whatever you want directly in the component itself. So you don't need to write a React query to go reach out to an API and bring it back. You can do the API or even database query straight in the component, and then process that data, massage it into the HTML that you want, and opt into client side components only in the parts of your app that actually need it.

So the ultimate goal there is making it easier to write server side logic within your component so you can co-locate things, avoid shipping API keys and bundles unnecessarily, and letting you use new patterns inside of frameworks like next, where you wanna have nested layouts and all of the troubles you might have run [00:08:00] into if you're using next 12 and before, that's more domain specific stuff.

So if we're in the next JS crowd, Try the app directory to see if it solves some of your problems. But if you're generally in the React community, look at server components, see how they work. Try next GS since it's the only way to try them right now and decide for yourself if it simplifies your logic a little bit, cuz server only is definitely a nice model.

Shaundai: That was a good explanation. I'll also add that with server components and this is also the case for server side rendering now, especially with React 18. But with server components, it gives you the ability to decide. Component by component, whether or not you, how much you wanted have it be client facing versus server facing.

And as Ben talked about, it's one of the bigger issues is that even server side rendering alone is a, and I say that because you're not just doing server side rendering or just doing server components. It's a combination of both. When you're doing just server side [00:09:00] rendering . Pre-Act 18, you are making decisions for your entire app, and you're running through all of the steps of the server rendering process for your whole application. When you render the H T M L To the client and show it in the browser. You have to couple that with JavaScript in order to hydrate.

And you need to hydrate in order for your app to become interactive for your users to be able to use it. Most apps these days have a large amount of JavaScript, and the time that it takes before your app is interactive depends on the amount of JavaScript that you're using. So now you can say, okay, this component.

Requires a lot of reinders or it requires a lot of JavaScript and you can decide component by component , from a performance perspective, whether or not it's worth it to. Go through and have it rendered fully on the server and have it be interactive on the server as well.

Or if you wanna do that combination of server plus client with traditional server side [00:10:00] rendering with React.

Emily: That might actually be a good segue, , but we did get another question from Hassan. That was asking when should we use server versus client components and react. Again, correct me if I'm wrong, if this is a good or not segue if we recovered this, but I think people are probably confused about what are the client versus server components in this case?

Shaundai: Let's talk about it from the perspective of server side rendering versus clients side rendering. And this is straight from Dan Abramoff. It's not server side rendering or client side rendering. . Server rendering is considered an optimization on top of client rendering.

So you're technically doing both. Let me make sure that I make it clear so that I'm using the correct terminology. So explain just a quick difference between client only rendering and server rendering. React by default. Your app is using client only rendering to render your app, and the big difference is in what your user experiences as that JavaScript loads.

So in a traditional client only rendered app, [00:11:00] we need to go through the process of loading the JavaScript on the browser. When you're rendering a page, but because a lot of apps will have these heavy JavaScript bundles, it can take some time Before that Java script is loaded and. , if your user has a slow internet connection, it can also take a lot of time for that JavaScript to be loaded while that JavaScript is being loaded, all your user sees is a blank screen.

And then once the JavaScript is loaded, then everything is hydrated. H T M L is rendered, your CSS is attached. Your JavaScript bundle is attached, and then your user sees your fully interactive site, right? It takes some time. So if you have a smaller app just a personal website or something.

Usually just basic react with all of the Optim performance optimizations as is enough, so you don't necessarily need to go through the extra steps to server under your app. Now the problem that server rendering solves is that, again, if [00:12:00] your app has a large JavaScript bundle size, so if you have a bigger app, you're working with an enterprise level application or you have like heavy amounts of data or something, it's gonna be much longer before your user is able to see something on the screen because, As you add more JavaScript as you have these bigger requests for data it takes some time to get to that step where we're loading the JavaScript and hydrating.

So you don't want your users to see that blank screen. So instead with server rendering, what your app is able to do is the initial Fetching data will happen on the server, and that's a quicker process because you're fetching the data from the backend and versus a round tripp from client to server to client, so that process happens faster. And then once you fetch the data for your app, on the server, React is gonna walk the component tree and render all of your components to HTML and send that to the browser. So your user, even though you haven't loaded the JavaScript yet, which might take [00:13:00] some time, if you have a bigger app, your user is actually able to see.

The content on the screen while that JavaScript loads. So for your user, it provides a better experience. They're able to actually , not necessarily interact with your content yet, but it makes your app seem more performant because they're not looking at that blank screen while the Java was script loads.

So all of that to say if your app is bigger, , if you have heavy JavaScript bundle sizes, if you have a lot of data that you need to fetch and your user is gonna experience possibly, or probably those long JavaScript load times, I would say server rendering might be worth it to use in that case.

Ben: Yeah, and just to make it more complicated, I'll throw in server components because that actually adds a third layer. Which is an interesting one. Cuz , as you explain what server rendering, that's actually been a model that's been around for a few years now in frameworks usually need a framework to help you [00:14:00] do it because it's not the easiest thing to set up yourself.

You're using VE or create React app. You don't wanna set up server rendering cuz it's just difficult. But server components are this third layer where you can line them up in a line where you have server only components. You have hybrid components that are server rendered and run on the client, and then you have client only.

Those are three options available and react now and in next chance is still the only example, which makes it a little bit more annoying to explain. But with that new model the bias is meant to be server first. Where when your original question was about server versus client. Maybe when should I use one versus the other?

If you're talking about server components, the biases start with server components for everything. And then opt over to clients when you need to have some interaction, like the form example from earlier where you need to track on change and you need to do client side validation instead, so you can push that closer to the user.

So [00:15:00] when you're doing server only as I mentioned earlier, these components can literally be ay, where you can, at the top of a component called albums, for example, the first line of that component can be a weight DB fetch. Albums, you can co-locate the whole query. You can render it out to H T M L, and then you can add in more components from there.

Because it unlocks so much when you're doing server only, it's nice to buy. Its towards it so that you can just do whatever wackiness you want within a component. SQL injection aside, be careful, but when you want to go towards client only or when you wanna go towards client, that's when you want to reach for interactions.

And the low wrinkle there is client components are actually. Server rendered components still they're in that hybrid model of it's going to server, render it, and hydrate on the client. So be aware that when you're using client components, that does not mean client only. It is still going to do a pass on the server to get those benefits that we heard earlier.

So that part is not [00:16:00] going away. It's just less often that you have to deal with it because you can stay in server only for the components that support it.

Noel: Yeah, I think the way that I think about it is hopefully ssr. Like the rendering for the most part, we, you don't have to think too much about, as a developer, like you enable it, it happens, it just does its thing. And then if you're using next in that world, then you are really thinking in terms of using server or client components and that's where you're spending your decision time.

not to say that you should like, just forget that there is like the pre-end stuff happening on the server, even for client components. But I think the vision is that devs don't have to like, Be thinking about that all the time as they're developing.

Emily: Next question. Victor coming in again asked how can one optimize application performance using the transition tracing api, and for probably those who don't know, what is the transition tracing api?

Ben: There's two things that are called transitions and , it could be referring to either one. I'm gonna assume they're talking about the [00:17:00] react transition hook, because I found on Facebook's React repo, they do call it transition tracing a P I and one commit.

Maybe that's what you found, but I assume it's not the View transitions api, which is very new in niche. But if you're talking about transition, that is a fun one. Because the use case that I found for it, and this is a new model again related to react server components where you can react to changes usually during routing and display some sort of placeholder ui.

While that transition is happening, a common example is you type in a search box and you want to fetch some more results from the server, maybe using a server component. Anytime that search input changes and when the search input changes, you don't wanna have zero feedback. You wanna have some little loading indicator while that new server component is being processed and streamed down the wire and use transition is a way to hook into that [00:18:00] life cycle.

If you're using a framework like next, it has a transition hook set up already for you that's going to let you track that transition. So when you type in that search box, you can say, use transition to say, Hey next, anytime that you're changing routes. Tell me whether it is pending, which is like a loading state, and I'll display some UI while that transition is going on.

So you can track it with is pending. You can show a little loading indicator while the new search is coming down the wire and then when it's ready is pending, will be flipped back to false and it will show the new UI. And I've also heard use cases around transitions being a way to show UI, a non-blocking way while stuff is coming down the wire that's more nuanced and complicated.

I usually use transition as just, you want to track that change is happening to the page and you wanna show some placeholder UI while that change is happening. So if you keep that mental model to start, it's pretty easy to pick up transition and use it for those sorts of states. The nuanced stuff I'm still playing with.

Emily: We're [00:19:00] gonna move on to More speculation, but also you guys are, you're experts in your field. So I think you can probably speculate pretty well on this one. But uh, Jordy asked do you think there might be something included in the react core for data manipulation at some point?

We have Redex, we have React query. So I'm interested if we can expect something like that to be integrated into the reactor at some point. 

Shaundai: In general, I see the React team and the problems that they work to solve as more of Let me caveat this. This is all speculation. I don't work for the React team. And I don't know what their thoughts are. , these are my own personal thoughts on it. But in general I see React as a library for rendering and displaying things in a very user-centric way.

I see them solving problems that both. Optimize the user experience or enhance the user experience as well as the developer experience. And the problems that I've seen [00:20:00] lately that have been solved really over the history of React are in general like, How can we make it easier for developers out of the box to be able to create these really great experiences for their users.

Now, data manipulation is a part of that, but there are so many aspects to data that like those problems can be, you could have a whole entire company team dedicated to just solving how to best Fetch data and things like that. I do see there is like a, there are two, different islands that I picture in my head, which is the data part of it, and then where the data gets piped into the front end and how the user sees it and how we break things up a data perspective and a JavaScript perspective to get things on the screen and make .

What the user is interested in interacting with, making that part of it as interactive [00:21:00] as quickly as possible. And part of that is just only bringing in the data that's relevant to the current user or that will be displayed on the current page that's being rendered. And then how we. Change or massage that data so that it's in a format that is optimal for the user, which.

In over history, like that's more for the engineer to figure out how to massage , that data. So all that to say I personally don't see much of the data fetching coming from the React team, like that part of how we get the data. But I do see maybe possibly some optimizations in the way that we massage data.

I don't know exactly what that would look like, but once we've fetched the data from, the server. How do we get that data in a great format? Or how do we break up what's come back from APIs if you're using rest, for example? How do we break that data up in a way [00:22:00] that is more performant, more digestible?

And they'll be more responsible for solving these problems. I hesitate because I don't wanna speak for the React team, but I don't see too much in the future from like the fetching perspective, for example.

Ben: Yeah I hate to say that there's not as much speculation these days, but they actually did chip some data manipulation stuff, or they're at least trying to, so it is changing rapidly. Because that perspective on reactors for massaging data, that has been how I've looked at React since I tried it a long time ago.

But now that they're trying server components comes up in every conversation, I'm sorry, but it is how they're trying to push the architecture right now. So you have to bring it in. But they're playing with now that you can now that React has some control over how things are rendered on the server.

They're playing with something called Server actions, and I'm still confused on if this is a next JS Alpha or a React alpha. They're [00:23:00] one in the same right now, so I can't piece it apart, but it's an alpha and it is a way to write what is called an R P C endpoint. So it's a very small endpoint that you can import directly into a client side component.

And you can pass it some parameters and it will give you a response all with type safety down the chain. So you can write literally a function inside of a file called Use server at the top. And it is a server endpoint in a way. And once you import that into a client component, it turns it into a data fetcher.

So it will give you the typed result of whatever that function is trying to return, but it'll let you call it either from a server or a client component. You can go crazy with it and you can massage that result into something. So this is very early days in how they're playing with it. But I think the React team decided if we're going to shift over to having opinions on the server, we should probably have opinions on server endpoints and fetcher's as well.

[00:24:00] So server actions are a way to go from a client component back to the server, get some more stuff and bring it down. But that doesn't. Cross out libraries like T RRP C and React Query and all these other more exotic tools that have a lot of like cash invalidation. That's not something in server actions at all yet, but it's still very fundamental to the stuff that you do.

So those libraries should stick around and I think server actions will need to grow around that. But they are playing with this early days idea of what if we can let you import server functions and call them? And how would that serialize, how would that bundle, let's have some opinions around that. I feel like it'll be at least a year or so out before libraries and ecosystem catch up to those patterns.

And you can use them in your apps. I would say React qury and community libraries are still the way to go for like the next year maybe. But beyond that, reacts starting to have opinions and we'll see where it goes. They could also just scrap it if the community doesn't like it at all. That's what Alphas are for.

But it's nice if they're trying it.

Shaundai: One [00:25:00] thing that I liked that reacted a couple years ago was they had the oh, I forget the name, but I was part of it. It was a committee like they pulled people from the React community and got their feedback on the beta versions of things like React 18. I was part of this group.

And so one thing that I do like about the Rya community is that they don't just throw spaghetti at the wall and, say, okay, this is what we think is cool, so this is what we're gonna build. They're actually out there getting feedback from the users and seeing What's interesting, what's new in the world.

I know that there's, like you said, Ben, there's been a ton of conversations about server components and it seems like people are leaning toward needing those problems to be solved or wanting those problems to be solved right out of the box with React. That's one thing that I really admire about the team is that they're very much in tune with what's going on and what their users are needing.

Ben, I think you might have convinced me that maybe they are gonna lean more into the data manipulation space because that is what people want and this is what they want out of the box from React as well.

Ben: Yeah. I like that they let [00:26:00] libraries move first where they can see what are the most common things that these libraries are doing and not how can we replace a library, but how can we build really nice primitives that could just make that library easier, take some load off of them. Like we already know, you're all trying to do some sort of data fetching option with some type safety that bundles correctly.

So let's give you a primitive to write a function that does that. If you wanna write a rapper library for caching for R P C endpoint I can't speak to that as much cuz I don't write dynamic apps as much anymore. But if you wanna have opinions about that, we'll just make those libraries easier to build without trying to replace the community because they care so much about backwards compatibility.

It's not even funny. Like you can still use a class component in a React server component if you want to, something from like 2016, you wanna just hotwire it to see if it works. It'll still be there. So I don't think they're trying to break existing patterns at all. I think they're just trying to underpin libraries and give them the resources if they want it.

Emily: With that we're gonna take a quick break [00:27:00] and when we come back we will talk about React performance. This episode was brought to you by Log Rocket. Again, log Rocket offers session replay, issue tracking, and product analytics to help you quickly surface and solve impactful issues affecting your user experience.

With Log Rocket, you can find and solve issues faster. , improve conversion and adoption, and spend more time building a better product. Again, you can try it today@logrocket.com. All right, and we're back. We're gonna go to Armin. They asked, the hardest part I encounter when dealing with React apps is performance issues.

I start checking Reinders, async calls and different things. But my question is, what is the best paradigm or approach to tackle performance issues, which is a big question.

Shaundai: That's a big question. I talk a lot about performance and it became a big interest of mine when I started at Netflix because obviously we care about [00:28:00] perfor, everybody cares about performance. I shouldn't say that, but the performance of the way that I attack. Performance issues is different than I've handled it at any other company.

And so this is a very broad question. So I'll answer it in a very broad way. One thing to think of, actually, two things to think of. Our keys when it comes to performance, you don't have to do everything. There are so many ways to optimize on performance, and sometimes you can actually decrease the performance of an app by trying to fit in every single optimization.

I wanna do code splitting. I wanna use this framework on top of this library, on top of this library. And you can end up with a really bulky app that doesn't do. That much. So when you're investigating, how am I gonna optimize my app? What tools, resources APIs am I gonna bring in to help with my performance?

Make sure that you understand [00:29:00] that , these are the benefits, but also understand the trade-offs of it and decide for yourself as the engineer which way you're going to attack. Now , that leads me to my second. Point when it comes to performance issues, the performance essentially is your user's experience.

It's how are they able to come to your app and see what they intended to see, do what they intended to do in the time that they are trying to get it done. very vague, but. The thought is that you want to focus on your user's experience and as front end engineers, that should be , our North Star is how is our user's experience gonna be the best.

So put yourself in the shoes of the user. And make decisions when you're thinking about these trade-offs, this library versus that library. Think about it from the user's perspective. Who is my user? What is their persona? What types of things are important to them? An example that I use from my actual life. [00:30:00] I have a five year old and during Covid he was like, yeah, during the heat of the pandemic. He was home with me all day and I took him out of his little daycare, but I still wanted him to learn. So I got him all these apps so that he could, use his little screen time hard out and learn his ABCs.

And there was one app in particular that I paid like $60 a month for, and. I thought it was gonna be great and it was a great app, but the loading time, because they were trying to fit so many different, Pieces into it. The loading time was insane. And to think okay, your user is two-year-olds, they don't have the time.

Like they really don't have they're in a rush. Like they, they don't have the time to sit there and wait for things to load. And then If you're gonna have like long loading screens, you need to make it something interesting. It can't just be like a little loading spinner that I recognize, but a two-year-old wouldn't recognize, make it like a cute little animation that, gets them involved.

I would [00:31:00] say like one, just really the big, again, the big north star is your user, what they can bear and optimize for that. And then if you're interested in finding out more about performance, I would start, and this depends on what type of app you're building, because I build web apps and , the majority of my users are using Chrome.

I would start with The core web vitals so the core web vitals, if you're not familiar, are performance metrics that Google has come out with and they continue to iterate on. For example, first input delay, which is currently a core web.

Vital is soon to be replaced by. Interaction to next paint, I think is what I N P stands for. But they're constantly iterating on what these metrics are gonna be. So they're performance metrics that. Will help you to understand the health from a performance perspective of your web app. And they're user-centric.

And so Google, as big as they are, understands that the [00:32:00] main. Goal when you're thinking of performance and how we should measure it, is the user. And I think that's a great place to start. You can go to , web.dev/vitals. They have excellent documentation. Learn about the metrics, why they're important, and then start from there.

Run your app through a lighthouse report. Get the stats on your existing app, and then With the lighthouse, they'll give you an insights into where you can improve performance for your app. So that's my way to tackle that broad question.

Noel: Yeah, I'll just add on, . Use your browser's tools , like a browser can generate a lighthouse report for you. There's, all kinds of performance tools right in the browser. Open up that profiler it sounds like. Yeah the person asking the question is already doing that based on how they worded it.

But I think that's a good place to start for people that are daunted like your browser profiler will highlight things in red and yellow and show you where to start looking like a lot of work has been done here to make this . As easy as it can be for devs. It's hard because this question is so [00:33:00] context specific, right?

Like what is good performance is gonna vary vastly dependent on app and like how can you improve that is also gonna vary. I dunno, take some time iterate. , if you're at the scale where you can like, build this into your testing pipeline, it can help you like stay on top of this and keep track of regressions and stuff like that.

Figure out where your performance started slipping, which can help you optimize down the road. But I know that's not where everybody's at. Yeah, I know U use the tools in your browser.

Ben: Yeah, it's all right there. And the dev tools to come with your framework. Of course. Webpage test is one that I've played with a little bit, but it's really intense. That's a last step of seeing absolutely every monitor that you could want. I think they also put a fresh coat of paint to make it more approachable, so that one will give you a ton of insight into like specific font files that are slowing down your website.

That was one that it caught on my personal site. Also figuring out which JavaScript is good, JavaScript and which ones are actually bad. There's definitely a fight to get the best lighthouse scores when really shipping some JS is actually better. [00:34:00] So don't always assume the 100 is the only metric because they're adding more core web vitals also, which is the set of tests that Google will run when you do lighthouse.

And yeah, it's really context dependent. If you're building a super. Interactive studio of some kind, and the initial paint is slow, but subsequent interactions are much quicker and pre fetched and all of that is good. Then you might decide to throw away the lighthouse score and just trust your gut.

So that's up to you to monitor in a more case-by-case basis. But if you're building more static stuff that's servers rendered, then yeah, the browser defaults are probably gonna give you what you need.

Emily: We have one more question from Alex. They asked the introduction of Hooks and React changed the way developers built apps. What do you expect will be the next paradigm shift in React and is it server components? I'm just

kidding.

Ben: components. That's all I got.

Yeah.

Shaundai: Yeah, 

Noel: on the server. Yeah.

Shaundai: like we talked about this already, but yes. Server components. Server [00:35:00] components. Server components. That's what's on everybody's mind.

Emily: Any far out wild predictions you might have? What do you wanna see and react.

Shaundai: Everybody's moving toward type script and , I can't really even articulate what type of Issues I have with TypeScript. I guess probably just the same issues that everybody else has is that TypeScript can be a pain to deal with when it comes to error messages and like figuring things out it means and then how to resolve it.

So maybe I'm not really sure, like maybe I guess this is a small kind of thing, but it's hard to, especially if you're a newbie two type script, it's hard to understand , what different types you would need for basic react component, like event handlers and things like that.

, just the different aspects of. The basic react components and APIs and things like that. So I don't even [00:36:00] know what it would look like at all, but if there's anything that can save me from the hassle of trying to figure out , how to type things and type script or get me further along with fewer errors that I have to manually resolve and figure out, then that's completely welcome.

But that's all I can think of.

Ben: To me that feels like an AI thing,

Shaundai: Yeah.

Ben: depending, don't wanna take us down that road, but some way to take, yeah. Whatever your bundler outputs and make in summarizing, Because AI is something you can't always trust, but it's good at summarizing stuff and I think it could summarize, here's a hundred line type script where the last line is the only one that actually matters.

It could actually bring a piece out. Yeah, it's actually that type. Here's the file, go to it. But I don't know if that's react specific. I think that's just web. Yeah. And sorry to cut you off. Sorry about

Shaundai: No, that would be a beautiful world. You saw it?

Ben: It would mean nice.

Emily: All right. Easy peasy. That was the end of our questions. Thank you everyone for coming on today. Sh day. Where can people find you?

Shaundai: Yeah, [00:37:00] so one of the benefits of having a unique name is that my first name is my handle for everything. If you're looking for me, mainly I'm on Twitter at sh day, s h a u n d a I. For those listening in, you can find me on GitHub at sh day, Instagram at sh day. Dev two sh day shonda.com, like the possibilities are endless.

If you are interested in more information about type script as well, I'm working on a course on type script with the good folks of egghead slash skill recordings. And you can go to the website for updates and freebies. So it's ts for js.com, that's ts f o r js.com .

Emily: Awesome. Ben, where can people find you in anything fun you're working on right now?

Ben: I wish I had a name like Sean Day. I'm on the other end of the spectrum. I'm competing with, I think uh, saxophone is, and a baseball player on the Google search results.

Emily: I can confirm that.

Ben: Yeah. Sorry I've been fighting, I don't know, but [00:38:00] at this point I go by my handle. I thankfully got that on all the platforms, so it's consistent.

But be Holmes Dev Holmes is in Sherlock Holmes. I'm on Twitter, YouTube, TikTok doing very short form explainers on a whiteboard. And if you wanna see an archive of all those videos, wtw.dev. This is where you can go. This stands for Whiteboard the Web, and I have videos there every week, breaking down stuff in one minute, including React server components if you wanna catch up on that and understand what that new shift means.

I have stuff on transitions and streaming and new fundamentals you might wanna learn. So that's probably my fun project that I'm working on. And I also work at Astro. Go try Astro. It's a nice model. It lets you use anything you want. Also brings server components to the table. Good for content sites. So yeah, go check out those things.

Emily: Noel, 

Noel: you can find me here every few weeks on Potter Rocket. Yeah.

Emily: All right. Thank you everyone for joining us. I really [00:39:00] appreciate everyone coming on and sharing your expertise. And for those listening, if you have any specific questions about web development, you can message me, Emily, on Twitter at Emily k Ketner, K e t n E r. I'll also put that in the show notes along with everyone else's handle.

And we might feature your questions in a future episode, so let me know what you have questions about and we'd love to talk about it on our next episodes. Thank you again everyone for joining us today, and hopefully we'll see you again soon.