Dev Tools Q&A

[00:00:00]
>> Often do you need to defer to the Chrome Dev Tools when you work on the React application what are the cases. Let's say, when is the React profiler not enough?
>> I mean, so it's tricky, right? Like insofar that I'm working on a JavaScript application, so stuff like the debugger and break points and console logs.

[00:00:21]
It is tricky for me to delineate cuz I am in them all the time, right? I would say that I still just generally did my code behave the way I wanted it to, stuff like the elements in the console and some of the other pieces are still incredibly useful to me.

[00:00:38]
I think it's when I know I have a problem. And for me, part of the reason it's really hard for me to answer that question is cuz if any of the tools are open, I'm still getting those green flashing boxes. So I'm simultaneously looking at my console and getting information from the React tools at the same time.

[00:00:55]
So for me it's ubiquitous in both cases which is one of the things I really like about the tool.
>> And the second question is how much overhead does the benchmarking itself add? So let's say if I'm noticing a particular number, do I need to discount it by a certain percent when assuming it runs in-

[00:01:15]
>> I don't know if there's a heuristic. It is multiple times slower, right? I've even heard the word exponential thrown around, that sounds like hyperbole, right? But I think it is saying that it is maybe two to three times slower is probably fair.
>> So the general heuristic I think we could agree on is that if you're running and you see proportionally that this has decreased, that means you've improved.

[00:01:39]
But the exam it probably will be even more performant once you run production build without the overhead of the.
>> Yeah, and it depends on the size of the code base and stuff like that. There is a way to build a production at least in create React app.

[00:01:53]
And there's different ways for every different setup, whether you're using Vite, Webpack, your own thing. There are various ways to also make a production build that has the profiling in it, right? So you can get a closer to a real number and the regular Chrome tools will work on a production build, you just won't get a cheat sheet to what component it is, right?

[00:02:14]
The thing that is costing you all that extra time is all the information that makes it useful. But yeah, to your point, especially if one has a system where they can kind of a lot, they have metrics in their build process to be like, it doesn't necessarily matter if it was 60 milliseconds in development mode, if it is 12% worse than it was last sprint.

[00:02:39]
Yeah, that's still a problem right and so the relative numbers are still useful for figuring out if you have an emerging issue. But yeah, it's just one of those things which is the exact number, you shouldn't take particularly seriously because it will be inflated. First, we're gonna talk about Steve's Golden Rule of Performance, which I alluded to earlier and ruined.

[00:02:59]
I forgot that I made that animation because I felt it was that important. We will talk about the corollaries doing this, which is, anything you don't do is faster. It's like preventing renders but also preventing memoization, preventing renders, everything you don't do is faster than doing it and that's ultimately what performance comes down to.

[00:03:18]
It's not like computer spending extra time thinking and pondering life, it is doing extra work that you have deemed unnecessary, right? Or as we'll get to the very end of this course, it is doing work that is necessary at a time that is not optimal, right? And where we end at the very end and just kinda like paint the picture, which is sometimes you're doing a thing that, yeah, it takes a lot, right?

[00:03:46]
What the concurrency APIs in React do that we'll see towards is they allow you to say like, hey, but first, maybe we react to their actual typing and clicking. And then we can go back to doing the expensive thing, right? Because that's really what we care about, right?

[00:04:02]
Long things might take long. Absolutely, but we wanna get to the point where, okay, but our thing shouldn't totally freeze up, right? And we should still respond to keystrokes and stuff along those lines. But yeah, generally speaking, the recurring theme is not rendering is faster than rendering. Not memorizing faster than memorizing.

[00:04:26]
Loading stuff later when you need it is faster than loading in the very beginning. Yes, right. This is all true. Awesome, and so the color is, as I kinda mentioned, not doing stuff as faster than doing stuff, checking to see if you can skip doing stuff is sometimes actual work that was slower than doing it, right?

[00:04:47]
And this is why the measuring matters. If you think like, the thing's rendering, it shouldn't totally render. You should look at that and see how much it cost to stop it from rendering because maybe the act of rendering was faster than memorizing it right? And that's why we use the tools, that's why we use objective truth rather than just like I've written a blog post, I should totally do this.

[00:05:09]
Yep, and then, yeah, these things we'll see in the kind of third chapter of the course, which is putting stuff off is better. And then lastly, this is new to React 18. In React 17, everything was urgent, right? Well, it's one of those things, everything was equal. And if everything's urgent, nothing's urgent.

[00:05:29]
And so React 18 gives us the ability to delay between, this is important, this can wait, and we'll see how to use it in cases where we're stuck with some kind of issue.