Wrapping Up

[00:00:00]
>> Steve Kinney: So, two things. One, I will point out that for a lot of this, there are additional notes and stuff like that for some other things that you might be interested in and pull requests accepted and stuff like that, because these did for a lot of cases just start as my personal notes. But definitely for more things that might be interesting, absolutely check that out. But now I have one less promise that I have to fulfill, which is to bring back the slide that I showed in the beginning of effectively where we can kind of use with suspense, holding on to the promises, memoization, the component hierarchy, do that first, right?

[00:00:41]
The stuff that has always been true of pushing state down to the lowest level you can, you know, as high as you need, as low as you can get away with, the memoization, stuff like suspense, which is not particularly new in the suspense stuff, but the idea of not waiting for useEffect, right, opting into these APIs, get you both real performance gains by not rendering when you don't need to, pulling in something like the React compiler to do the heuristic for you, right, on a consistent level.

[00:01:11]
The transition API, when you have those truly problematic, there's not really, yeah, sure, optimize that algorithm as much as you want, right? But at a certain point, it's still going to probably take more than 16 milliseconds across a wide range of devices, just because it works on my machine fast does not mean it works on everyone's machine, right? And a lot of these core things that again, the way they manifest themselves to us can be relatively simple things, right?

[00:01:43]
Yeah, and I think there's some conceptual things, and that's why we kind of tripled down on some of the conceptual pieces so that when I see useTransition, it's not magic. I understand that there are priority lanes that React Fiber uses. I understand that this puts in a different priority lane and lets my other stuff happen up there faster, right? I understand that some of the stuff about the optimistic updates, you've been able to do long before React was a thing, right?

[00:02:09]
You could always put something, you know, with jQuery, you could go put it in the DOM and wait to see if the promise rejects and take it out of the DOM, right? But giving a lot of just kind of these easier boilerplates for these things, right? Like I said before, some of the stuff we didn't totally dive into because I think they're mostly covered in kind of the higher level of just like suspense will wait for a promise to resolve is better than useEffect, right, in a lot of cases, because otherwise you would have waited for everything, then you would have triggered a whole bunch of useEffects.

[00:02:44]
Each one of those would have started a render phase again, and each one after that would have then cascaded and you would have had this waterfall of effects, right? With Fiber, when you opt into these new features, right, that piece, it will show that loading component and it will wait until that is resolved, and then it will pick up that work, right? Even if there's a second commit afterwards, right, all of that is possible and the heavy lift is not often that a giant, much more complicated rearchitecture ends up with a series of simpler APIs for us all to use, right?

[00:03:25]
I, you know, for a long time, I went on a side quest into Svelte for 4 years, right? But some of these like use and suspense and optimistic updates that I was still doing by hand even over there in modern versions of React are incredibly compelling and take out a lot of the stuff with the suspense that I like. We didn't get all the way into it today because, yeah, it's a performance thing, but it's a lot of times even just a TypeScript ergonomic thing where I know that what follows a suspense, like, you know, render, a resource will be fulfilled.

[00:03:55]
It will either add it up to the error boundary or it will have the value, and now I don't have to spend the rest of the component tree going, is a post or maybe it's null if I haven't looked for it yet, all throughout my entire application. Some of these abstractions, while they might feel like, oh my God, they had more things to React, actually end up becoming a little more elegant and simpler, right?

[00:04:20]
And thinking about that process of the structure of your application, where your data is coming from, how to actually leverage the performance optimizations in React itself, and because 19 and 18, I think for the most part have been backwards compatible, right, which means in a lot of ways, getting the most React performance involves opting in to all the work to make React more performant, right? On one hand, they didn't break your app.

[00:04:54]
I have done upgrades to Ruby on Rails, right, and stuff like that where it's a clear out your calendar for a month, even, you know, other frameworks where it is a clear out your calendar for a month. It was like, oh, we have a month with not a lot of deadlines. Let's sneak in the Svelte 5 and Tailwind 4 and all of these other upgrades, right? React has done a pretty good job of stabilizing and being backwards compliant, but for a lot of the performance gains, yes, thinking about the structure of your state and, you know, when you need to render and when not is still important, but that's always been important, right, and it will remain important because that's just a fundamental way that React works.

[00:05:35]
But a lot of React performance is actually thinking about the performance optimizations in React and then taking advantage of them, right? And don't do it all at once. Find a place, find, especially with stuff like the transition, there's not a need to do it all at once. You only need to do it in the places where you have that giant bottleneck, and there's one in every application somewhere, right, all the time.

[00:05:58]
And finding those places, and again, some of that involves either with the React tools and learning how to use those to see them, or also just the Chrome ones and being like, oh, we're pegging the CPU at 100% for 4 seconds. Start there. Don't start by being the worst person in a code review, right? That thing is like, it's 1.1 milliseconds, but if you memoized it, it would be 1.05 milliseconds. Don't do it, don't be that person, right?

[00:06:31]
Because most of us are also trying to ship software to our customers instead of just tweaking stuff and trying to be the coolest person on the block. But finding those places and using those tools to find the things that are pain points and realizing that there can be sometimes elegant abstractions for that. And I think that whether or not you have committed the useTransition hooks to memory, I don't care.

[00:06:58]
Do you understand that there is the ability to have high priority work? I trust that you can then Google the rest, or look at the notes, or rewatch that section, or what have you. The important part is the conceptual parts of like, oh, there is this idea of lanes. There is some ability for me to assign stuff to lanes, right? Getting those conceptual pieces is arguably the part missing from most people I talked to when I'm just like being a super cool guy hanging out with my friends, talking about front end.

[00:07:27]
I don't know why I do it. I just have friends who are software engineers. It's terrible, and we whine about things and I don't want to talk about them with them, so I changed the subject to stuff like this. And so finding out that there are these patterns and stuff along those lines and questioning some of the assumptions of like, does it need to be like this. That said, like I said earlier, if you have a whole bunch of stuff where you're setting the state of loading and error and stuff like that, that's not a tomorrow thing.

[00:07:55]
But it is a way to progressively get to move these things. I wouldn't say like, and I'm going to just find and replace all useCallbacks and put the React compiler and you will probably cause an outage, right? But for those pain points and to progressively apply them, which is really the kind of core understanding, honestly, from the beginning of this workshop and then kind of seeing it in practice to prove that it wasn't all just hypothetical talk, I think is incredibly powerful.