Steve's Rules for Performance

[00:00:00]
>> Steve Kinney: Kind of two like established jokes early on so I can reference them through the rest of the course. We're going to talk about Steve's rules for performance, right? These are like, they're laws. Right, like, you know, Newton's laws of physics and stuff like that, these are inalienable truths about performance that I will go to the grave with my golden rule. Is that not doing stuff is faster than doing stuff, right?

[00:00:32]
And that applies in all sorts of ways, right? Like code that doesn't have to run is way faster than code that you have to run. And there will be some nuances to this, right? Like, for instance, you'll be like, well, I'll just memoize all the things. Memoization is doing something. Caching is doing something, and if the cost of caching saves you from having to do more stuff, then it works. But if you're doing more stuff, then it saves you, then it doesn't work.

[00:01:04]
Always doing less will always be the fastest, right? Theoretically, I think I make this joke again in a few slides, but you know, whatever. You know, a React app that doesn't ever have to re-render is arguably the world's fastest React app. You could also argue, shouldn't that just be an HTML page? I'm not taking those kind of questions right now. But the, you know, as an ideal, you know, every step closer we get to never re-rendering is arguably going to be more performance.

[00:01:35]
So figuring out how do we not do stuff is a core both life tenant as well as a performance tenant in our application. And that was like the only rule that I had for the longest time in the early versions of this course and workshop. And then like I said before, React put a whole bunch of new performance primitives into the, you know, I think React still goes, it's not a framework, it's a library, whatever.

[00:02:03]
There's a whole bunch of other stuff in there now, which inspired the second rule, which arguably I could have split into two or three, but I got tired of making slides, which is feeling fast is pretty much as good as actually being fast, right? And then like that, like if the thing is snappy to my, if I'm typing and it doesn't feel laggy, the app itself does not have to be any faster. It just feels fast to me, right?

[00:02:33]
Preloading stuff, is that technically any faster, right? No, but it felt faster. Optimistically updating the UI when the server hasn't responded yet. Is that actually making the server faster? No, but it feels better than like seeing nothing for a little bit. And so we'll look at some of the primitives in there as well. And the kind of corollary to that is a lot of these performance primitives that we'll see with like the useTransition hook, useDeferred value, and other hooks are basically saying like, if you do this stuff I care about first and take equally as along with the stuff that I don't necessarily care about, right, then that's good to me, right?

[00:03:18]
Because I think it's a really tricky thing when we think about performance, we hear these things of like, you know, time to first, you know, meaningful paint is like means how many people bounce from the New York Times, yada yada yada. That's true. If you're building a content site. It's absolutely true. And you should probably be thinking about like what the like, you know, critical CSS is and stuff along those lines.

[00:03:43]
But at the same time, most of us will like watch that little Gmail loading bar. At the same time, right? And like, what does it mean for an app experience versus I shouldn't have been looking at this like webpage anyway, I should get back to work. If that is slow, there you're more likely to bounce. So figuring out like what performance means for your application. How do you do the critical stuff first, right?

[00:04:09]
And that's true for a content page, like getting the like words to show up correctly, and then maybe loading the other stuff is probably more important to make sure all the ad tracking stuff is there first and then loading the content. Versus if you are building an application, like they're in it for a really long time, having someone pay a slight cost upfront to then have every interaction be snappy is different, right?

[00:04:32]
And so a lot of these tools allow us to kind of like pick and choose which one is correct and right. And so this is the last slide. Like it's also the last slide. I will show it to you a second time at the very end. But to keep on the theme of like, let's talk about where we're going, and then we'll arrive there is, you know, there's kind of, if I think about like all of the pieces, there is like how we actually shape our app, right?

[00:05:02]
That kind of stuff where it's like good no matter what, is also performant, right? That can have like the largest impact. If your page isn't re-rendering needlessly, because like your state is kind of like in the right places and like properly cached and memoized, like, that's, you know, it doesn't have to re-render. No, doing less stuff is faster than doing stuff, especially stuff that doesn't need to happen, right?

[00:05:31]
Like memoization can be good, it can also add a whole bunch of problems, right? Like the famous quote of the two hardest problems in computer science are naming things, cache invalidation off by one errors, right? Cache invalidation being the important one there. It's like if something isn't loading because it thinks it already hasn't memoized and actually has changed, those are incredibly hard bugs to solve for.

[00:05:55]
And a lot of times they're bugs you caused by getting a little carried away with putting React.memo on everything all the time. Especially stuff that didn't need it, because now you're saying, hey, go check to see if we need it. It's doing something to find out that it didn't need to do that. Which is now slower than not doing it, right? And so that is always a careful balance of the line we're going to kind of walk, using like suspense and some of these other things to progressively load our application and like only getting the parts we need now and getting the other parts we need later makes me feel like it's faster, because like it is.

[00:06:30]
And then finally, like, we'll talk about the, you know, some of the transition APIs like useTransition. We'll get to the conceptual parts in the beginning, so that when we kind of pull that train to the station, like we are mentally prepared for them. A lot of what these APIs do is they give you the ability to say like, what is important and urgent and what can wait. And in earlier versions of React, you had no ability to do this, right?

[00:06:59]
And if you're like, I've been doing React for like 7, 10 years, and you're like, I've never used those, maybe you should. I'm not saying like they definitely solve specific kinds of problems. We'll talk about the class of problems that they solve, how they solve them sometimes in like 5 lines of code. Right, like, you like new features, those gotta be complicated because React used to be simple. React has gotten a lot more complicated under the hood, but I would argue some of the like newer and more complex APIs are shockingly simple to use.

[00:07:29]
It's just like once you wrap your brain around them and know that that tool is available to you, know that you have more than just one hammer in the toolkit. Because in the beginning, you kind of only had one hammer. Now there's like 4 or 5, and we'll talk about what some of those new hammers are and the nails that they fit.