React Performance Q&A

[00:00:00]
>> Steve Kinney: Uh, if you were handed a React app and needed to improve the informant, what's your first step? Or what's your process for identity was like my career for like a horrible amount of time. Like, just to give some context as I answer that question, like, up until like recently, my job—I didn't never intended, this is not what they asked me what I wanted to do in kindergarten—was to like go work at like these like SaaS companies that were all about their APIs.

[00:00:30]
Oh, APIs, we only care about our APIs. We're an API company, and what happens is those companies neglect there you are for like a decade, and they become very popular, and it turns out that you at one point run out of developers when you start winning, and you realize that there are more people who are not developers than real than there are developers, and you can get a bigger total addressable market.

[00:00:52]
So like, a large part of my life is taking neglected code bases for like a decade, and they're like, we care about this now. So it's a really tricky question because some of the answers to this question is not technical. Right? A lot of this question is like organizational, right? Cause like, a, like a big enough app to be a problematic a lot of times involves many teams, right, who are all trying to just meet their deadlines and do the best they can, and like the areas of the most pain no one owns, right?

[00:01:22]
So part of it is like, we'll take away the entire like hearts and minds thing of getting buy-in from all the teams. That is arguably job number one. Let's assume you're asking me a technical question and not a, uh, like, uh, you know, a leadership, whatever question. I think figuring out where the biggest pain point is, like I worked on this one app where, um, you know, the, you know, there's this balance between team autonomy and a like UI experience that is not like 7 versions of React loading, because every team had autonomy and stuff along those lines, right?

[00:02:01]
And it's really tricky because teams want to move fast, the organization decided to do this and you end up in these issues. So, if one goes to the app and like getting that first, anything on the screen is 90 seconds, well, guess what? That's the first place to start, right? If that is like, you know, moving stuff into a monorepo or like figuring out how to like get everyone pointed at the same version of React, then how do you manage like everyone upgrading to a new version, so on and so forth.

[00:02:33]
Figuring out, is it not loaded or is it like the APIs are like you need 10 API calls to do anything. Is that then like a backend for frontend strategy, right? Or is it simply like finding, you know, there was this tool for measuring Ruby on Rails' performance like a decade ago called Skylight, and one of the metrics that they used, um, for like triaging your performance issues was called agony, right?

[00:03:01]
And agony was slowness times traffic. Right, so if your terms of service page is really slow, you should probably get to that eventually. If your login page is slow, that's the highest priority, right? So it is unfortunately a hand wavy, it depends answer, but I think figuring out where the biggest pain point is, and like, it might even just be that like CI/CD fails all the time, so everyone like skips it, right?

[00:03:29]
Figuring out where that thing is. But like, ultimately, if it's just simply like for the stuff we talked about today, it is opening up those like React dev tools and the Chrome developer tools and like watch where all like the, like you'll know when something's flashing that shouldn't be flashing. Right, like having made a bunch of small apps for this, like, let me tell you, when I made that anti-social network app, I was focusing on like highlighting, um, like the, where to put the optimistic update.

[00:04:00]
You saw that thing flash in places it wasn't supposed to be flashing, right? It was, um, and like, when you're making 11 apps for a workshop, sometimes, you know, you miss a few things. And I think like seeing where you see stuff flashing where it's not supposed to be flashing, stuff longer is at least a place to go look, and it might be like, hey, the cost of touching this is not worth it, right?

[00:04:21]
Like, uh, you know, I've worked at companies sometimes where it's like everyone wants to refactor that thing written in Perl, but no one knows exactly how it works, and it hasn't broken in a decade, and sure it's disgusting. You don't touch that. Right? And so figuring out like where those places to slowly, uh, make things, you know, better are, but that's, it's one of those things where it's like, I can give you like high level guidance, but the specifics are so unique to every single large app.

[00:04:54]
But I think it, whether it's like, um, the initial load time or like seeing the fact that every keystroke or like some of the worst and most insidious ones are, you load that page, it's fine. You keep using it like 5 minutes, it's a little worse. It's a little worse after that, right? And if obviously it was obvious, somebody would have fixed it by now, right? But this is where having those tools is, I think, incredibly important and that like, kind of just that scientific approach of like, hey, I have these tools at my disposal.

[00:05:26]
I have these like ways to evaluate at my disposal. How do I kind of like, one, knowing that some of these solutions exist, which is my goal today, and then 2, also learning how to use the tools to like find them to see like, that's a very long line of a thing that shouldn't have been re-rendering. Maybe something flashes, but it was like one millisecond, don't fix that. Honestly, like, but if something flashes and then you look in the tools and it was like 1.3 seconds, that's where you start, you know, um, but that's going to be unique and different in every application.

[00:06:00]
So unsatisfying answer, but honestly the honest answer, so. I just have one question. Uh, you use the memo function, which, um, effectively if the props don't change, it doesn't re-render. Like, why isn't that a reacting itself, like where it's everywhere? Yeah, because sometimes something not changing could be bad. You know what I mean, like, especially like, maybe that component didn't change, but his grandchild needed that.

[00:06:30]
Right, so now it goes, hey, I don't change, which means it doesn't call its child, which means that one doesn't call its child, and so now 3 components down in a prop drilling thing that definitely cared about that, it's like, hello? Hello. So you can't like just like apply it like, um, you know, here's now theoretically, with React compiler, what it seeks to do is like, cause React at runtime doesn't have insight into the code.

[00:06:59]
Right, so it just had to assume that it couldn't possibly know. The goal, and if React compiler does what it, what it says on the tin, right, it should be able to like read that code. Oh, that imports these other functions, and it calls it here, right? Let me go down and go through it. And I have reason to believe that it will work insofar that like Svelte does it, Solid does it, many other frameworks do it, and they work, right?

[00:07:21]
Um, so there's no reason to believe that wouldn't. But previously, if you're just in the execution of the code, you don't have insight into actually what's getting called down below, um, because you're just the one passing it down to the children, you wouldn't have passed it down to the children and thereby it's like, well, I guess I'm not updating. Cool, because it wouldn't even know, you know. Function has the component has to be pure too, doesn't it?

[00:07:44]
I mean, if it's really tricky because if it has a hook, you can memoize it all you want. If that hook changes, it's still re-rendering. It won't re-render from the props coming in. So you would both get the problem that Samantha was talking about, and then also not get any performance gains, right? Uh, so you'd have a combination of both problems, and that's why they're just like, um, heuristically doing it everywhere all the time is dangerous, right?

[00:08:17]
Because yes, it will be more performant and broken. I will take a slow app that works over a fast app that doesn't do what it's supposed to do every time, you know, and that's the gambit that we play. And also the gambit of like, you know, um, it is, it is tricky. Do you want a perfect app that isn't done and never ships? You know what I mean? What's that, what's that Reid Hoffman quote, if you're not embarrassed of the first time you shipped, you ship too late.

[00:08:47]
You know, like, there is something about like, did you perfect this thing that it turns out no customer actually wanted anyway? Wolf, you know, like, and that's always the trade-off between like the like, uh, ivory tower version of a lot of this advice and the realistic version, right, which is like, we needed to get something out that like to even to see if anyone wanted it, not because like the boss said so, but like, honestly, I say this now as somebody working on like a startup idea that I have not released yet.

[00:09:16]
Should I just release the bad version and find out if anyone's even interested in it before I like really polish it up, I found out nobody wants this thing. And that's, I think, the eternal trade-off where it's like we blame people, it's like, why didn't they follow like this guidance from like some thought leader, because the world is hard, and we have to make trade-offs and balances and like every, like, you know, with React compiler is a great example.

[00:09:46]
If we can come up with a heuristic, we can automate it. We're only left with the squishy weird stuff. That's why we get paid what we get paid though, so that's great. Are you a fan of the paradigm of splitting out UI from state and handlers into separate files to have pure or as much as possible UI components and logic wrappers that add state and handlers, and they're asking kind of in the context of Redux.

[00:10:28]
Yes, do I always do it? It's like, no, this is a question I've been struggling with and been asked for like a amount of time that I admitted would start to explain the gray in my beard, uh, which is they're like, I think any super like hardcore take is wrong. So let's say you say everything should go into Redux, what have you. The open and close of that accordion, does that go on Redux? Does it? Uh, then, then, so not everything, right?

[00:11:04]
Like, uh, then where do you draw the line, right? Um, I think is tricky, like I, you know, I think that like, uh, you know, I like, I like the paradigm of Redux of like a function, current state of the world goes in, new information goes in, new state of the world comes out. I think that that is easy to test. Yes, can you mount components using testing library? Of course you can. Right? You know, it's really easy to test?

[00:11:31]
Put object representing current state of the world, a new thing in function, see what comes out the other end, right? Like, pretty, pretty elegant. I think that kind of stuff, but like, do I need that for like a certain amount, like, do you separate the idea of like your data, uh, like state versus your like UI state, what, what's open and closed, what's, you know, like whatever, and I think that's, uh, you know, an interesting if you think about like, in like distributed systems and like backend engineering, a lot of times there's like this difference between the data plane and the control plane, right?

[00:00:00]
And like the control plane being like all the widgets and knobs that you turn in the AWS dashboard, the data plane being like Dynamo and all those kinds of things, right? Do you use different approaches for those different things or do we just say that, oh, it's in the UI I like follow this rule all the time. It's tricky and I don't know that I've ever gotten it 100% right, you know.