Frameworks and Layout Thrashing

[00:00:00]
>> Steve Kinney: There is a issue here, right? I only had to solve this problem because I was keeping my state in the dom, right? I had to go measure stuff before I could mutate it. I don't keep my data in the dom anymore, I write angular or ember or react.

[00:00:17]
I keep things in state, right? So you could for instance put together some kind of component like this which keeps track and this is a half component, it's what I could fit on a screen. I'm gonna keep an array of all of my width. I'm gonna shoot them under the page over here and then I will just double those numbers and re-render.

[00:00:40]
Before you would not have to read from the dom and if don't read from the dom you can write as much as you want. You're never gonna have a layout trashing issue, never is a strong word cuz I showed you one, it was in react, but generally speaking this very isolated incident that should solve all of our problems, right?

[00:01:00]
So lets see what happens, it turns out I have a React running with this React app running, with the same thing going on.
>> Steve Kinney: And we can measure it, we can compare the differences.
>> Steve Kinney: So go ahead, do a recording.
>> Steve Kinney: And you can see that, wow, this is kinda weird.

[00:01:40]
There's a lot of stuff happening in here. That's not great. I told you you can get React information in the user timing API. So you can see, this is reconciling the React tree and an app update, so on and so forth, right? There's a lot of stuff happening here and 57 milliseconds isn't great for changing a bunch of bars.

[00:02:00]
But it turns out that I am committing one of the worst crimes in web performance which is, I'm using React in development mode and expecting production level performance. React does a bunch of stuff. I told you before, measuring takes time. So React is doing a whole bunch of stuff in development mode to give you these pretty things and manage a whole bunch of stuff.

[00:02:24]
And checking prop types and all these things and that stuff is slow. And so if you have the React developer tools sometimes you can see a page where this will be black if it's using React in production mode and it will be this like scary orange if it's used in development mode.

[00:02:42]
As fun to like keep that going, just go visit sites that are still running in development mode. I mean, and it's like one of the things sometimes I think says they do it on purpose I mean if they say it, that means they know about it and they've decided that that's now their new state.

[00:02:56]
Right, some websites are totally doing it by accident sometimes it's like don't know about it and sometimes it's like somebody tried to change the webpack build and now we're accidentally shipping the development code, right? This has happened to my app a few times. So this is really helpful.

[00:03:11]
So it turns out 57 milliseconds we're doing all of this extra stuff. That's not great, right? So having it in development mode is suboptimal. Let's actually compare what that looks like though, because it turns out that I also have a version of this app in that repository that is built for production mode.

[00:03:30]
So let's go ahead and actually, I should have it over here. Same application, let's record it again. Wow, that's much better right? That's...let's compare and contrast. Giant spike of sad yellow. Little bump. Alright, the simple fact of being in development mode is a huge difference versus production mode.

[00:04:08]
Right, now you can see there's still a bunch of stuff happening here. And this is again the eternal trade for performance when it comes to using a framework, right. The framework is gonna make decisions a lot of the time for you. It make it easier to keep your state out of the dump which like helps you avoid layout trashing.

[00:04:24]
They like batch all your dump things for you but they are JavaScript code and they take a certain amount of overhead Right? And that is always the tradeoff you need to make. I am of the belief system that generally, especially if you have a team and you have a wide range of experiences and you're trying to get product out the door that the cost of using a framework is beneficial for you, right?

[00:04:43]
But if you had a bunch of, if you sat there and really wanted to fine tune your application, hand-crafted application will probably be faster But like, probably not worth it. But yeah, you can see there is some overhead. But you can see that we're still at like, 9.3 milaseconds.

[00:04:59]
I'm gonna call this a win, right? It's just something to consider and something to think about.
>> Steve Kinney: So yeah. Friendly fact, production mode is important in React. I have another slide that's gonna say this again later, because I've literally made this mistake multiple times. So I feel like if I keep repeating myself, you will think about it.

[00:05:20]
And if you don't write React, there's probably a version of this for your application and is definitely worth checking. Cuz there was a dramatic change of 9.3 milliseconds. I figured what the first thing was, but it was a lot longer with a lot more sadness in that graph.

[00:05:33]
So definitely make sure you're using production mode for whatever it is. All right, cool. So
>> Steve Kinney: So it doesn't, does React solve your problems for you? Right? Maybe, maybe not, right? You can still see that slide that I showed earlier where I have a React app that still has this problem.

[00:05:57]
It's not gonna get you all the way there. Having a framework is helpful, you still need to be mindful. You still need to measure. Right and these things can still happen. I assume with your question you're thinking about like what was the answer to this. I don't know yet.

[00:06:10]
I haven't dug in. [LAUGHS] But looks like I've got a few little issues here on the simple drag in and drop in button and like I measured it and now I can go ahead and fix it. So kinda key takeaways here are don't mix reading layout properties and write them, you'll do unnecessary work.

[00:06:27]
Also, if you can just change something by adding a CSS class, kinda going back to that style calculation, we don't read that at all. This one, we want to double up a bunch of individual bars. But with just adding a class, you will cause one reflow, but there's no way that you can get yourself into that loop.

[00:06:43]
So, if you can handle this by just having a CSS class that has the second state that you want versus trying to do it by hand and calculating everything, go for that. That is always going to be the safer option for you. In storing data and memory, whether it's in react,2I stored it in the state, in that case I showed you earlier.

[00:07:02]
But like, you know, you could easily just keep it in array somewhere in memory if you were doing this by hand. There's nothing React, and Angular, and Ember, all written in JavaScript, right? Anything you can do with those frameworks, you could do on your own. Like, keeping all those widths in an array was probably smarter than keeping them in the dom to begin with, right?

[00:07:19]
That's not always an option that you have, right? Like, when I'm editing user content, right, I don't always have that luxury, right? So it's something to keep in mind either way. You don't need a framework. You can do bad things still, if you have a framework, as I showed you.

[00:07:33]
I'm guilty of it. And finally, the major point is you might not even know that you're layout thrashing, cuz I didn't until I went to take that screenshot. That's kinda like the moral of the story.