Fuld transskription af Exploring ReactScan: Aiden Bai's Tool for Identifying React Performance Issues - JsJ 668

correct. Like basically how React works under the 37 00:02:19.800 --> 00:02:23.759 hood is it takes like two versions of the view, 38 00:02:23.800 --> 00:02:26.039 so like the old version and the new version, and 39 00:02:26.080 --> 00:02:28.240 then it reconciles it, like it figures out the differences 40 00:02:28.240 --> 00:02:30.879 between those and then it applied it to the actual dome. 41 00:02:31.800 --> 00:02:35.719 But like this is like an an operation or some large, 42 00:02:35.960 --> 00:02:41.159 big old notation that's over one. And the problem with 43 00:02:41.199 --> 00:02:46.199 that is if when the versions get really big, like 44 00:02:46.280 --> 00:02:48.840 the trees get really big, you're doing a lot of computation. 45 00:02:49.800 --> 00:02:51.439 So I was like, okay, wouldn't be cool if you 46 00:02:51.439 --> 00:02:54.520 could pre compile this, Like okay, based on the JSX 47 00:02:54.599 --> 00:02:58.800 you provide. There's like obvious points where it actually changes, 48 00:02:59.039 --> 00:03:02.080 like when you have those JSX container expressions, like the 49 00:03:02.680 --> 00:03:05.879 when you passing some data in, So I pre compile 50 00:03:05.960 --> 00:03:09.199 that and then found like the specific code paths that 51 00:03:09.240 --> 00:03:12.159 matter to make the dom changes. So every time you 52 00:03:12.199 --> 00:03:15.360 render a component, instead of doing that whole reconciliation process, 53 00:03:15.719 --> 00:03:20.479 it just changes the dom like like pinpoint processes, basically. 54 00:03:21.360 --> 00:03:26.000 Kind of implementing fine grain reactivity in a sense over 55 00:03:26.159 --> 00:03:27.159 on top of React. 56 00:03:27.280 --> 00:03:30.719 I guess, yeah, like benef it's a fine grain reactivity, 57 00:03:30.719 --> 00:03:32.560 but without using fine grain reactivity. 58 00:03:33.800 --> 00:03:38.479 Yeah. I think you kind of mentioned several things that 59 00:03:38.520 --> 00:03:41.919 are kind of important in the context of React performance 60 00:03:42.000 --> 00:03:45.280 as you were describing this. I think that first and 61 00:03:45.360 --> 00:03:50.520 foremost is this whole thing about virtual dom and the reconciliation. 62 00:03:52.080 --> 00:03:56.120 We actually had a couple of chapters in JavaScript jabber 63 00:03:56.240 --> 00:03:59.840 talking about the virtual dom, what it is, why it exists, 64 00:04:00.000 --> 00:04:03.280 et cetera. But I still think it might be worthwhile 65 00:04:03.319 --> 00:04:05.680 to talk a little bit about what it is because 66 00:04:05.719 --> 00:04:08.439 it's so central to everything we'll be talking about today. 67 00:04:08.960 --> 00:04:10.800 So can you tell us a little bit about you 68 00:04:10.919 --> 00:04:13.400 the virtual dorm from your perspective. 69 00:04:14.439 --> 00:04:20.480 Yeah, virtual dom is basically it's kind of an overloaded term. 70 00:04:21.000 --> 00:04:24.600 It's basically taking two like versions of the UI and 71 00:04:24.600 --> 00:04:28.079 figuring out the princess between them and then actually changing 72 00:04:28.120 --> 00:04:32.439 the UI. React doesn't actually hold the dom tree inside 73 00:04:32.439 --> 00:04:34.079 of itself. I mean it kind of does, but like 74 00:04:34.600 --> 00:04:36.959 when it does when it figures out what to change, 75 00:04:36.959 --> 00:04:40.079 it doesn't actually store the dominodes as the whole tree 76 00:04:40.120 --> 00:04:42.240 and then dip the dominance. It difts like a virtual 77 00:04:42.319 --> 00:04:46.680 version of it. This can lead to some problems. So 78 00:04:47.000 --> 00:04:49.959 for example, like for Facebook, it might be somewhat okay, 79 00:04:50.360 --> 00:04:54.600 like when you were switching pages, but like if you 80 00:04:54.720 --> 00:04:57.800 are creating like a stock trading app, like a stock 81 00:04:57.839 --> 00:05:02.480 treating dashboard, where like there needs to be like updates 82 00:05:02.519 --> 00:05:06.160 every several like some amount of milliseconds, or you're making 83 00:05:06.199 --> 00:05:11.160 like significant dom mutations every single second, or if your 84 00:05:11.240 --> 00:05:15.439 website targets it targets like very low end devices, then 85 00:05:15.639 --> 00:05:20.160 that sort of mechanism can lead to some performance problems. 86 00:05:20.480 --> 00:05:25.160 I think the key aspect here is that React took 87 00:05:25.279 --> 00:05:28.759 what I considered to be kind of an idealized approach 88 00:05:29.360 --> 00:05:34.959 to UI generation, which is, let's in an ideal world, 89 00:05:35.000 --> 00:05:39.120 I would say react. The React approach is, let's take 90 00:05:39.160 --> 00:05:44.399 the entire application state and apply like a function to it, 91 00:05:45.120 --> 00:05:50.519 a pure function even that generates the UI that the 92 00:05:50.639 --> 00:05:56.360 user sees, and that every change in the state would 93 00:05:57.240 --> 00:06:02.480 ideally again regenerate the entire UI. So you know, you 94 00:06:03.199 --> 00:06:06.079 check or uncheck a small checkbox in the UI, and 95 00:06:06.279 --> 00:06:10.639 theoretically the entire user interface of the application gets re 96 00:06:10.639 --> 00:06:14.560 rendered because then you don't need to think about state 97 00:06:14.680 --> 00:06:18.439 changes in the user interface. It's just everything again and 98 00:06:18.480 --> 00:06:22.959 again from scratch. But the problem with this approach is 99 00:06:23.279 --> 00:06:29.120 that a naive implementation would obviously be just way too slow. 100 00:06:30.399 --> 00:06:33.399 It's kind of taking, by the way, the approach that 101 00:06:33.480 --> 00:06:36.800 we had in the old days of the multipage applications 102 00:06:37.360 --> 00:06:41.319 and kind of applying it to the client side rendering 103 00:06:41.360 --> 00:06:45.800 mechanism that we have in JavaScript code that updates the 104 00:06:45.879 --> 00:06:49.759 don in that in

the old days you would go 105 00:06:49.800 --> 00:06:51.399 to the back end and then you would get the 106 00:06:51.519 --> 00:06:53.639 entire page back each and every time. So it's kind 107 00:06:53.680 --> 00:06:56.199 of like doing that, but again but doing everything on 108 00:06:56.240 --> 00:06:59.920 the client side and doing it for every state logical change. 109 00:07:00.759 --> 00:07:04.879 And the virtual dom was like the first thing that 110 00:07:04.920 --> 00:07:08.560 they implemented in order to make it viable the from 111 00:07:09.000 --> 00:07:11.920 the perspective of performance, that is the virtual dom. By 112 00:07:11.920 --> 00:07:15.000 the way, it's a fancy term, but really really all 113 00:07:15.040 --> 00:07:20.000 it means is JavaScript objects. Really, that's all the virtual 114 00:07:20.000 --> 00:07:24.560 dom is. So instead of having actual dom elements, which 115 00:07:24.600 --> 00:07:28.639 are rather heavy because of all the functionality that they encapsulate, 116 00:07:28.759 --> 00:07:34.160 you just use JavaScript objects simple JavaScript objects as stand ins. 117 00:07:34.199 --> 00:07:37.279 And like you said, when the state changes and the 118 00:07:37.319 --> 00:07:41.120 new virtual dom is created, React then takes the new 119 00:07:41.199 --> 00:07:46.439 virtual dome the old virtual dome, does a comparison, finds 120 00:07:46.439 --> 00:07:52.519 the differences, and then calculates the minimal amount of actual 121 00:07:52.600 --> 00:07:55.680 dom changes to transition from the first state to the 122 00:07:55.720 --> 00:07:59.839 second state. And that's the reconciliation process. And for a 123 00:08:00.079 --> 00:08:03.040 long time it was thought that it was that approach 124 00:08:03.160 --> 00:08:06.000 was good enough in terms of performance. But like you said, 125 00:08:06.639 --> 00:08:11.800 when user interfaces started becoming more complex, complicated or more complex, 126 00:08:12.600 --> 00:08:17.800 and as we needed to support lower end devices like 127 00:08:18.040 --> 00:08:22.879 more mobile devices for example, and as we needed more 128 00:08:22.920 --> 00:08:27.360 frequent updates, even this type of optimization started to break 129 00:08:27.399 --> 00:08:35.840 down because doing all this reconciliation work still has overhead, 130 00:08:35.879 --> 00:08:38.720 and this is when million js, I guess came in 131 00:08:38.759 --> 00:08:41.399 to start to try to reduce that. But like you said, 132 00:08:42.240 --> 00:08:46.200 being able to be smart about pinpointing the exact locations 133 00:08:46.200 --> 00:08:49.200 of the differences and not having to do the entire 134 00:08:49.240 --> 00:08:53.879 comparison of the entire virtual dom tree, right, yeah, exactly. 135 00:08:55.080 --> 00:08:58.600 I view like virginal dom is more of in historical context, 136 00:08:58.679 --> 00:09:02.600 like it's more of getting things correct. Like before people 137 00:09:02.679 --> 00:09:05.799 use like Backbone or they roll their own JavaScript libraries 138 00:09:06.399 --> 00:09:10.799 and this would literally results in like like there were 139 00:09:10.840 --> 00:09:14.279 literally so many frameworks like bugs and these frameworks. Virtial 140 00:09:14.320 --> 00:09:17.519 dom is like a very exhaustive approach to the problem. 141 00:09:17.960 --> 00:09:20.679 But it's more likely to get things correct than that. 142 00:09:21.679 --> 00:09:24.799 Yeah, because when you're essentially building the entire UI from 143 00:09:24.879 --> 00:09:28.480 scratch from the current state, you don't have to worry 144 00:09:28.559 --> 00:09:34.840 about an incorrect UI transition or state transition messing up 145 00:09:34.840 --> 00:09:39.960 your display. I think, uh, Facebook had they had this 146 00:09:40.080 --> 00:09:43.559 story about one of the motivations for creating React in 147 00:09:43.559 --> 00:09:48.039 the first place, is that they had a counter in 148 00:09:48.120 --> 00:09:52.120 their user interface about the number of messages that you 149 00:09:52.240 --> 00:09:56.840 had pending or something like that. And any change to 150 00:09:56.960 --> 00:10:01.120 that mechanism was always buggy because they always had to 151 00:10:01.159 --> 00:10:04.120 somehow sync with everything else that was changing on the page, 152 00:10:04.200 --> 00:10:08.799 and because so many things were changing more or less 153 00:10:08.799 --> 00:10:13.360 concurrently in the UI, all of them as synchronous to 154 00:10:13.360 --> 00:10:16.240 each other, they would always get into age cases and 155 00:10:16.279 --> 00:10:19.679 age situations. And being able to just re render the 156 00:10:19.799 --> 00:10:25.039 entire UI from scratch virtually solve that problem very neatly. 157 00:10:26.759 --> 00:10:31.039 But again, so we had a couple of performance issues. 158 00:10:31.320 --> 00:10:33.919 One performance issue is the one that you addressed with 159 00:10:33.919 --> 00:10:37.399 the mini and JS, which is the fact that even 160 00:10:37.519 --> 00:10:44.080 that sophisticated reconciliation could be too slow, especially if the 161 00:10:44.200 --> 00:10:47.399 virtual dome was really large, especially if the device was 162 00:10:47.440 --> 00:10:50.039 low end, and especially if you did it very frequently. 163 00:10:51.080 --> 00:10:54.159 The other problem, I think is that even building the 164 00:10:54.240 --> 00:11:00.159 virtual dome, which is mostly just running your code that 165 00:11:00.320 --> 00:11:06.879 generates the JAX from the state, can be heavy and 166 00:11:07.200 --> 00:11:12.799 performance intensive if done too often, or if if it's 167 00:11:12.919 --> 00:11:16.799 just too complicated. And I think that this is where 168 00:11:17.120 --> 00:11:21.759 reacts can comes in, because it's that's your new project, 169 00:11:21.759 --> 00:11:24.240 the one that we're going to talk about, because it 170 00:11:24.399 -->

00:11:28.960 strives to, if I understand, correctly, minimize the amount of 171 00:11:29.039 --> 00:11:32.519 redundant helps you help you to minimize the amount of 172 00:11:32.559 --> 00:11:35.200 redundant rerenders that you perform. Correct. 173 00:11:36.080 --> 00:11:40.919 Yeah, exactly. I can give a brief introduct. Basically, react 174 00:11:40.919 --> 00:11:43.320 scan is a tool that helps you find like re 175 00:11:43.320 --> 00:11:46.519 rendering performance problems and you react ap today. You can 176 00:11:46.559 --> 00:11:48.200 just drop it in your app as a script tag 177 00:11:48.360 --> 00:11:52.240 and it basically highlights the components that render and potentially 178 00:11:52.279 --> 00:11:57.039 slow down your app. I spent like maybe three years 179 00:11:57.080 --> 00:12:01.639 optimizing websites, everything from like webar you see, like virtual 180 00:12:01.679 --> 00:12:04.720 camera websites to e commerce websites. There's like static sites, 181 00:12:05.919 --> 00:12:09.279 and when I try to debug these performance problems on 182 00:12:09.320 --> 00:12:12.639 these sites, it's really hard. Like it's either like I 183 00:12:12.679 --> 00:12:15.440 do console that time and time end, or I use 184 00:12:15.519 --> 00:12:18.440 Lighthouse scores, which is like at skill level zero to 185 00:12:19.440 --> 00:12:22.559 profiling tools and Chrum dept tools. React to have tools 186 00:12:22.879 --> 00:12:24.879 at like skill level one hundred, and so there's like 187 00:12:25.000 --> 00:12:29.480 nothing in between those those two types of tools. And 188 00:12:29.559 --> 00:12:32.639 this made me really frustrate, right, I Like I spent 189 00:12:32.799 --> 00:12:35.360 so long just trying to understand how these level one 190 00:12:35.480 --> 00:12:39.159 hundred tools work that that I realized that most people 191 00:12:39.320 --> 00:12:42.399 don't have the time or ability to figure it out 192 00:12:44.279 --> 00:12:48.039 exactly so react Skain helps bridge the gap. Today we 193 00:12:48.120 --> 00:12:52.200 do renders, but soon we'll support more stuff. More stuff 194 00:12:52.200 --> 00:12:55.360 in that like I n p cls LCP which are 195 00:12:55.440 --> 00:13:00.480 like the lighthouse Google Lighthouse scores, as well as stuff 196 00:13:00.480 --> 00:13:04.200 like lung tasks. F he has all of this, like 197 00:13:04.559 --> 00:13:08.159 metrics and stuff that take They are decently like, not 198 00:13:09.159 --> 00:13:14.039 like decently hard like recently not easy to measure correctly 199 00:13:14.519 --> 00:13:15.840 and interpret. 200 00:13:15.879 --> 00:13:20.279 Basically, so you threw out a bunch of metrics and then, 201 00:13:20.399 --> 00:13:24.399 as I mentioned, metrics are near and dear to my heart. 202 00:13:24.559 --> 00:13:26.960 They're part of what I do on the W three 203 00:13:26.960 --> 00:13:30.600 C Web Performance Working Group, which I'm an invited expert on. 204 00:13:33.559 --> 00:13:38.960 I think the three main ones referred to as unsurprisingly 205 00:13:39.000 --> 00:13:41.679 as core web vitals because they are the core ones. 206 00:13:42.080 --> 00:13:45.039 We talked about them on the show on several occasions. 207 00:13:45.799 --> 00:13:48.919 I think we even had specific episodes dedicated to them. 208 00:13:48.960 --> 00:13:52.799 But still again, it might be worthwhile to mention what 209 00:13:52.840 --> 00:13:55.000 they are and what they measured. Do you want to 210 00:13:55.039 --> 00:13:57.879 do that or should I? 211 00:13:57.879 --> 00:14:00.399 I can explain like ten seconds like I'm he is 212 00:14:00.399 --> 00:14:04.080 basically interacting in a page and getting the result back visually. 213 00:14:04.799 --> 00:14:09.919 LCP is basically the largest like content fil basically any 214 00:14:09.960 --> 00:14:13.360 elements with text or some big text in it. In 215 00:14:13.440 --> 00:14:17.320 it is the like however, time it loads and then 216 00:14:17.960 --> 00:14:22.799 CLS is basically how much your page layout shifts. You 217 00:14:22.840 --> 00:14:25.080 want your IMP to be as low as possible, you 218 00:14:25.120 --> 00:14:27.879 want your LCP to be low as possible, and CLS 219 00:14:27.919 --> 00:14:29.360 to be low as well. 220 00:14:29.639 --> 00:14:34.679 Yeah, exactly. And it's interesting because there they are not 221 00:14:35.000 --> 00:14:39.919 trivial in the context of React especially. Yeah, and it's 222 00:14:39.960 --> 00:14:47.759 interesting because different facets of React address different these different metrics. So, 223 00:14:47.840 --> 00:14:51.360 for example, if we're talking about the largest content for paint, 224 00:14:51.519 --> 00:14:54.080 which like you said, is the amount of time from 225 00:14:54.080 --> 00:14:56.679 when the page starts loading until the largest piece of 226 00:14:56.720 --> 00:15:01.159 content is actually rendered on the browser screen, if we 227 00:15:01.200 --> 00:15:04.240 think about what React does to try to optimize it. 228 00:15:04.279 --> 00:15:07.799 So initially React, for those who who may not recall, 229 00:15:08.320 --> 00:15:12.799 was just client side rendered, and that kind of guarantees 230 00:15:12.960 --> 00:15:19.240 slow LCP by definition, because nothing is shown until all 231 00:15:19.279 --> 00:15:23.799 the JavaScript is downloaded, including React, and then the client 232 00:15:23.919 --> 00:15:26.799 side javascripts need to do the ajax calls to get 233 00:15:26.840 --> 00:15:30.440 the data and then render the UI based on the 234 00:15:30.559 --> 00:15:33.360 data and the code, and only then do you actually 235 00:15:33.679 --> 00:15:38.720 see anything on the screen. So that's when React introduced 236 00:15:38.720 --> 00:15:42.679 service side rendering, or SSR and static side generation or 237 00:15:42.799 --> 00:15:51.919 SSG with meta frameworks like next JS or remix. So 238 00:15:53.879 --> 00:15:56.559 it's by the way,

it's interesting in this context that 239 00:15:57.159 --> 00:16:02.559 still many organizations that I ounter don't really care that 240 00:16:02.759 --> 00:16:07.799 much about LCP in the context of React applications, because 241 00:16:07.840 --> 00:16:10.960 a lot of the web applications that are built using 242 00:16:11.039 --> 00:16:16.440 React are things like dashboard or internal enterprise applications, and 243 00:16:16.559 --> 00:16:20.360 there the approach is that it's loaded once and then 244 00:16:20.519 --> 00:16:24.399 used all day long, and therefore the loading time is 245 00:16:24.799 --> 00:16:29.159 less important. I actually think that in many cases this 246 00:16:29.240 --> 00:16:33.840 is a misguided view because, for example, let's say you're 247 00:16:33.879 --> 00:16:36.759 commuting to work on a train. You want to use 248 00:16:36.799 --> 00:16:41.279 that time you're connecting via VPN into your internal network, 249 00:16:41.320 --> 00:16:44.759 you're loading your internal application, and it takes your entire 250 00:16:44.840 --> 00:16:51.919 train ride to actually load, which isn't fun. But be 251 00:16:52.000 --> 00:16:55.679 that as it may. So that's LCP. There's the IP 252 00:16:55.919 --> 00:16:59.639 which you mentioned, which is how responsive the pages to 253 00:16:59.720 --> 00:17:04.160 interac actions, how long it takes the page from when 254 00:17:04.240 --> 00:17:07.240 you actually click on a button to actually render the 255 00:17:07.279 --> 00:17:11.799 result of clicking on that button. And again, React can 256 00:17:11.880 --> 00:17:16.240 be really problematic there because if it's doing very lengthy 257 00:17:17.920 --> 00:17:22.400 rendering operations or re rendering operations and you click in 258 00:17:22.440 --> 00:17:24.920 the middle of one of these operations, then it won't 259 00:17:24.960 --> 00:17:28.839 actually respond or do anything until all that JavaScript finish 260 00:17:28.920 --> 00:17:33.519 is running. And CLS, I think, is the one that 261 00:17:33.680 --> 00:17:39.480 is least directly related to React itself, because it's more 262 00:17:39.720 --> 00:17:42.440 it has more to do I think with how you 263 00:17:42.519 --> 00:17:47.359 start your CSS stuff like that. I would say though, 264 00:17:47.440 --> 00:17:55.319 that for people who are using what's it called React suspense, 265 00:17:56.319 --> 00:18:02.079 they need to watch out for CLS because if they're 266 00:18:02.640 --> 00:18:08.880 loading code doesn't match the size of the actual finally 267 00:18:08.960 --> 00:18:13.240 rendered component, then things will shift after the after the 268 00:18:13.359 --> 00:18:17.559 load the loader is done, So so you do need 269 00:18:17.599 --> 00:18:20.119 to watch out for that if you're using suspense in 270 00:18:20.160 --> 00:18:23.440 the context of React, I think would you agree with that? Yeah? 271 00:18:23.440 --> 00:18:24.720 Also for images, right. 272 00:18:25.680 --> 00:18:28.839 Yeah, but images are there, you know that's a universal 273 00:18:28.880 --> 00:18:34.960 issue that's not reacts butific Yeah, so million js kind 274 00:18:34.960 --> 00:18:39.799 of addressed I guess both LCP because you were running 275 00:18:40.759 --> 00:18:47.559 the rendering code faster, and also it kind of addressed 276 00:18:47.640 --> 00:18:52.240 I n P because it blocks the rendering time for 277 00:18:52.279 --> 00:18:56.359 a shorter period of time. What I understand that you're 278 00:18:56.359 --> 00:19:02.799 addressing with reacts scan is most about figuring out how 279 00:19:02.839 --> 00:19:08.000 to do less rendering and also generally make the rendering 280 00:19:08.039 --> 00:19:13.599 itself faster, which again will would primarily benefit I n P. 281 00:19:13.839 --> 00:19:15.359 I guess. 282 00:19:16.839 --> 00:19:22.200 I see it as like rendering is always somehow related 283 00:19:22.200 --> 00:19:24.039 to some performance problem on the page if you use 284 00:19:24.079 --> 00:19:29.000 it reacts site like I'll give a couple examples, like 285 00:19:29.160 --> 00:19:33.559 for example with with with CLS, right, it could be 286 00:19:33.559 --> 00:19:36.519 a styling issue, but as a user, I want to 287 00:19:36.559 --> 00:19:42.400 know like where that specific uh specific like layout ship 288 00:19:42.519 --> 00:19:46.279 is occurring with i MP. I want to click a 289 00:19:46.319 --> 00:19:48.200 button and I want and there's like maybe a bunch 290 00:19:48.200 --> 00:19:50.599 of renders. I don't know why it's slow. A rendering 291 00:19:50.680 --> 00:19:53.640 is somehow always somehow related to that, even LCP, as 292 00:19:53.640 --> 00:19:55.680 you said, right, like like if there's a lot of 293 00:19:55.680 --> 00:19:58.720 rendering on the page that doesn't need to render, like 294 00:19:58.799 --> 00:20:04.279 maybe below the folder outside the viewpoort, then it's not good, right, 295 00:20:05.559 --> 00:20:08.400 even like other performance issues like when FPS drops or 296 00:20:08.480 --> 00:20:13.160 like I'm trying to think of other examples, but like 297 00:20:13.160 --> 00:20:16.960 whenever the page feels sluggish, it's always rendering is always 298 00:20:17.039 --> 00:20:18.480 somehow related to the problem. 299 00:20:19.079 --> 00:20:21.599 So FPS, can you elaborate on what that is? 300 00:20:22.519 --> 00:20:26.079 FPS is frames per second? Basically this is important for 301 00:20:26.680 --> 00:20:29.279 movement or animation tasks, so like when you scroll the 302 00:20:29.319 --> 00:20:35.359 page or something is animating like rainbow gradient. For some reason, 303 00:20:37.000 --> 00:20:40.039 that FS is important. You want to usually keep it 304 00:20:40.079 --> 00:20:41.319 over sixty fps. 305 00:20:42.160 --> 00:20:46.359 It is the standard. And again JavaScript gets in the 306 00:20:46.359 --> 00:20:51.200 way because the main thread, well the browser is kind

307 00:20:51.200 --> 00:20:54.519 of not exactly but mostly single threaded, so whenever you're 308 00:20:54.599 --> 00:20:57.920 running JavaScript, it kind of blocks everything. And if you're 309 00:20:57.920 --> 00:21:01.920 blocking everything too much, then you get jank or jitter 310 00:21:02.519 --> 00:21:04.559 because you're not able, like you said, to hit that 311 00:21:04.680 --> 00:21:10.680 sixty fps. I totally agree with what you said about 312 00:21:11.039 --> 00:21:15.519 identifying things that render needlessly. My own experience is that 313 00:21:16.240 --> 00:21:21.079 a lot of React teams don't even ever get there. Basically, 314 00:21:21.319 --> 00:21:26.039 when they see that something that the UI renders correctly, 315 00:21:26.839 --> 00:21:30.160 that's good enough for them, and they don't care about 316 00:21:30.160 --> 00:21:33.319 the fact that it's rendering correctly over and over and 317 00:21:33.359 --> 00:21:37.319 over again, effectively doing a lot of work at the 318 00:21:37.440 --> 00:21:41.839 virtual dome level without actually ever updating the actual dome, 319 00:21:42.400 --> 00:21:47.799 because the reconciliation basically notices that they're just recreating the 320 00:21:47.880 --> 00:21:52.279 exact same virtual dome over and over again. But even that, 321 00:21:52.920 --> 00:21:57.480 even though it's cheaper than updating the dome, still you know, 322 00:21:58.400 --> 00:22:02.359 accumulates if you concer doing that you're literally just running 323 00:22:02.400 --> 00:22:06.200 an infinite loop of JavaScript that's doing nothing. Is that 324 00:22:06.240 --> 00:22:08.759 has that been also your experience that it happens in 325 00:22:08.839 --> 00:22:11.079 a lot of organizations and a lot of websites. 326 00:22:11.680 --> 00:22:15.240 Yeah, that's definitely one of the problems. It's also I 327 00:22:15.240 --> 00:22:18.799 don't think it's necessarily engineer's fault, right, it's really hard 328 00:22:18.799 --> 00:22:20.920 to care about these things because they're not visible. Just 329 00:22:20.960 --> 00:22:24.359 like if the page UI is not correct, it's very visible. 330 00:22:24.440 --> 00:22:26.799 You have to fix it. If there's an error, you 331 00:22:26.960 --> 00:22:28.519 have to fix it, right, It's not like you can 332 00:22:28.559 --> 00:22:31.559 avoid these things. The performance you can really easily avoid 333 00:22:31.599 --> 00:22:34.720 because most developers use like a really high end MacBook 334 00:22:34.839 --> 00:22:37.880 or high end PC where you can like any performance 335 00:22:37.920 --> 00:22:40.319 problem you can blaze through and like basically hit with 336 00:22:40.359 --> 00:22:43.920 no problem. And also developers are so used to slow 337 00:22:43.960 --> 00:22:48.599 build tools and slow like development startups that like one 338 00:22:49.160 --> 00:22:52.440 hundred three or real seconds it feels like nothing. So 339 00:22:52.480 --> 00:22:54.759 the problem is performance is not visible, and developers are 340 00:22:54.759 --> 00:22:58.079 really out of touch in touch with users for performance, 341 00:23:00.920 --> 00:23:04.119 like even even if even for like performance experts who 342 00:23:04.119 --> 00:23:08.880 like think about performance every day, they're also not super 343 00:23:09.000 --> 00:23:12.519 in tune with like the actual products performance Like maybe 344 00:23:12.519 --> 00:23:14.119 they go to data Dog and they see the metrics 345 00:23:14.119 --> 00:23:15.839 and they're like, okay, how can I improve this today? 346 00:23:16.119 --> 00:23:18.559 Or they see a regression in performance after a specific 347 00:23:18.640 --> 00:23:21.880 git commit, But then it's like, okay, what do I do? 348 00:23:22.039 --> 00:23:24.279 Like how do I reproduce this? It's kind of hard 349 00:23:24.319 --> 00:23:29.160 to do those things. Reacts again is our attempt to 350 00:23:29.440 --> 00:23:32.319 try to fix some of this, right, Like how how 351 00:23:32.359 --> 00:23:35.039 do we make performance visible? Like how can we show 352 00:23:35.079 --> 00:23:39.079 developers that there's problems on the side without like having 353 00:23:39.079 --> 00:23:41.279 them loaded up on a Moto G four or something. 354 00:23:42.559 --> 00:23:44.440 Moto G four, by the way, for those of you 355 00:23:44.519 --> 00:23:49.000 are too young to know, is an old Motorola phone 356 00:23:49.039 --> 00:23:55.720 that Google still uses virtually for simulating performance of websites 357 00:23:55.759 --> 00:23:59.680 on low end devices. If you're using Lighthouse, that's what 358 00:23:59.680 --> 00:24:06.720 they there. Okay, then so you want to visualize the 359 00:24:06.799 --> 00:24:10.400 performance issues, how do you go about it? What do 360 00:24:10.480 --> 00:24:12.960 you actually show? How do I see that I have 361 00:24:13.359 --> 00:24:16.440 a performance issue in my React website? By the way, 362 00:24:16.640 --> 00:24:19.480 the tool is for React, right It's not you know, 363 00:24:19.599 --> 00:24:21.720 for websites that aren't React based. 364 00:24:21.759 --> 00:24:27.039 Correct, Yeah, React for now? Right now? We highlight renders 365 00:24:27.119 --> 00:24:29.599 and if there is some sort of long task or 366 00:24:29.640 --> 00:24:32.720 FPS drop or imp that's really high. We turn the 367 00:24:32.720 --> 00:24:34.960 color of the renders to like from purple to like 368 00:24:35.039 --> 00:24:38.920 red or something. In the future, we wanted to have 369 00:24:38.920 --> 00:24:41.640 more visualizations, like when I click a button, what is 370 00:24:41.640 --> 00:24:46.039 the IMP or like the local tested imp we have 371 00:24:46.200 --> 00:24:50.519 like or like what is the like long animation frame? 372 00:24:50.839 --> 00:24:52.680 Like when a long animation frame happens. I want to 373 00:24:52.720 --> 00:24:55.599 see that the long animation frame happens. I want to understand,

374 00:24:55.640 --> 00:24:58.319 like when jink happens, or when jink happens, what is 375 00:24:58.720 --> 00:25:01.920 the cause of that. Jink renders is like our base 376 00:25:02.000 --> 00:25:06.039 abstraction basically, like usually it's always related to It's like 377 00:25:06.119 --> 00:25:11.119 always somewhere within the problem, and so we show it 378 00:25:11.240 --> 00:25:12.279 via renders basically. 379 00:25:13.240 --> 00:25:19.279 So basically, if I understand correctly, you're adding rectangles around 380 00:25:19.400 --> 00:25:24.240 the React components that get rendered. And these components and 381 00:25:24.279 --> 00:25:31.680 these borders kind of highlight whenever the component renders. So 382 00:25:31.880 --> 00:25:36.759 if it's constantly highlighted, you know that this component is 383 00:25:36.839 --> 00:25:42.640 for some reason being constantly re rendered. Right and and 384 00:25:42.680 --> 00:25:45.119 by the way, again, re rendering is at the virtual 385 00:25:45.160 --> 00:25:48.440 dome level, so even a component might be re rendered 386 00:25:48.519 --> 00:25:51.920 even if nothing actually is changed for it in the 387 00:25:51.960 --> 00:25:58.200 actual browser dom. Correct, yes, yes, So it's it's your 388 00:25:58.279 --> 00:26:02.119 code and React code doing work for that component, whether 389 00:26:02.279 --> 00:26:07.720 or not anything actually gets updated in the actual display. Yep. 390 00:26:09.400 --> 00:26:13.960 And usually the border would have one color what is it, 391 00:26:14.000 --> 00:26:17.440 Like you said, purple or something like that. But if 392 00:26:17.839 --> 00:26:23.559 it's resulting, if it's causing the browser itself to actually 393 00:26:23.880 --> 00:26:27.720 experience delays, then it will actually change color and become red. 394 00:26:28.279 --> 00:26:28.640 Exactly. 395 00:26:28.759 --> 00:26:34.799 Yeah, very cool. So I assume you've tested it on 396 00:26:34.880 --> 00:26:38.680 various websites and saw them flashing rectangles all over the place. 397 00:26:39.480 --> 00:26:42.759 It gives like interesting examples. 398 00:26:43.119 --> 00:26:46.400 A month ago, I founded this performance problem on the 399 00:26:46.440 --> 00:26:49.240 GitHub site when you would scroll on the code every 400 00:26:49.640 --> 00:26:53.759 line of coder Revender. So I tweeted it, got a 401 00:26:53.799 --> 00:26:57.039 lot of likes, a lot of views, and then I 402 00:26:57.039 --> 00:26:59.720 don't remember their name, but someone from the VP of 403 00:26:59.759 --> 00:27:02.640 the roll GitHub was like, hey, one day later, hey, 404 00:27:02.640 --> 00:27:05.400 we fixed this issue. When I tested it, the fs increased. 405 00:27:05.400 --> 00:27:08.240 Now it was like, holy crap, like's it was really cool. 406 00:27:08.279 --> 00:27:13.359 How just this random package we made and then just 407 00:27:13.359 --> 00:27:15.160 tweeting it out and just showing a video of it 408 00:27:15.200 --> 00:27:17.400 actually made a real performance change on the site. 409 00:27:18.519 --> 00:27:25.480 Yeah, yeah, that's really cool. And my experience is that 410 00:27:25.960 --> 00:27:29.319 it's exactly that that it's very difficult to notice that 411 00:27:29.400 --> 00:27:32.960 the problems exist, especially like you said, when developers have 412 00:27:33.079 --> 00:27:38.759 really high end max and stuff like that. But once 413 00:27:39.000 --> 00:27:43.079 you understand where the problem is in a lot of cases, 414 00:27:43.160 --> 00:27:45.279 not all cases, but in a lot of cases, the 415 00:27:45.400 --> 00:27:50.039 fix is fairly straightforward. You've got let's say, some use 416 00:27:50.079 --> 00:27:54.920 effect that's updating a state, which is retriggering the use effect, 417 00:27:55.079 --> 00:27:58.519 which is again updating the state and over and over 418 00:27:58.599 --> 00:28:02.039 and over again in this kind of an infinite rendering loop, 419 00:28:02.240 --> 00:28:04.480 something along these lines. Yeah. 420 00:28:04.759 --> 00:28:10.119 Yeah, the main hard part of performance isn't the solution. 421 00:28:10.160 --> 00:28:12.880 The solution space is actually really small. It's usually like 422 00:28:13.440 --> 00:28:17.000 one to five solutions for every problem, But finding the 423 00:28:17.039 --> 00:28:19.880 problem is the hard part. It's almost ninety nine percent 424 00:28:19.920 --> 00:28:20.279 of the work. 425 00:28:25.400 --> 00:28:28.759 Yeah, I totally, I totally agree with that. By the way, 426 00:28:28.799 --> 00:28:31.359 I'm just there are a whole bunch of sirens in 427 00:28:31.400 --> 00:28:36.799 the background, so I apologize for being a bit distracted. Yeah, 428 00:28:37.519 --> 00:28:41.160 that totally matches my own experience that it's sometimes that 429 00:28:41.759 --> 00:28:45.359 being able to pinpoint the cause of a performance issue 430 00:28:45.960 --> 00:28:49.519 is the hardest problem. But you know what, in that regard, 431 00:28:49.599 --> 00:28:53.799 it's not that different from a lot of bugs. You know, 432 00:28:54.039 --> 00:28:58.279 the famous Heisen bugs that happen occasionally are very difficult 433 00:28:58.359 --> 00:29:01.160 to reproduce and figure out, and then you know, you 434 00:29:01.240 --> 00:29:03.880 smack your head when you realize what the problem is 435 00:29:03.920 --> 00:29:10.440 because the fix is often very very straightforward. My question 436 00:29:10.559 --> 00:29:14.279 then is how were you able to get this information 437 00:29:14.759 --> 00:29:18.240 out of React? I mean, you know, React doesn't exactly 438 00:29:19.039 --> 00:29:21.880 tell you that, hey, you've got a performance issue. It 439 00:29:22.039 --> 00:29:26.400 just does this whole rerendering thing kind of automatically behind 440 00:29:26.400 --> 00:29:29.240 your back. So how did you figure this out? 441 00:29:30.559 --> 00:29:35.720 Yeah? Most simply so, React

dept Tools has information about 442 00:29:35.720 --> 00:29:38.440 componentry and renders. Well how does it do this? Well, 443 00:29:39.079 --> 00:29:44.519 React internally has it attaches like a property on the 444 00:29:44.519 --> 00:29:47.640 window object called React depth tools Global hook, and it 445 00:29:47.680 --> 00:29:50.680 has much of information about the fiber tree, and so 446 00:29:51.759 --> 00:29:57.599 reacts can internally uses that to get information about fibers 447 00:29:57.680 --> 00:30:01.359 just for context. A fiber is basically like the virtual 448 00:30:01.400 --> 00:30:05.640 do on how React internally represents the user interface. We 449 00:30:05.640 --> 00:30:08.480 can use the fibers to detect renders, and then we 450 00:30:08.519 --> 00:30:10.720 show those renders using a canvas on the screen. 451 00:30:12.400 --> 00:30:18.480 So base, ah, you're using You're not modifying the CSS, 452 00:30:18.519 --> 00:30:21.200 You're actually using canvas in order to draw the stuff 453 00:30:21.240 --> 00:30:21.759 on the screen. 454 00:30:22.440 --> 00:30:25.640 Yes, if we modify the CSS, there would be like 455 00:30:25.720 --> 00:30:28.640 some overhead on that, so any performance score you would 456 00:30:28.680 --> 00:30:30.839 see is going to be noticeably like it's going to 457 00:30:30.839 --> 00:30:33.519 be artificially inflated. So what we did was we put 458 00:30:33.519 --> 00:30:36.160 the canvas on a worker thread, so it doesn't have 459 00:30:36.480 --> 00:30:40.480 as much performance impact as if you actually modify the CSS. 460 00:30:42.319 --> 00:30:47.400 Ah cool, So what you're saying is you kind of 461 00:30:47.839 --> 00:30:54.759 put an invisible canvas on top of the entire rendered screen. 462 00:30:55.000 --> 00:31:00.400 I guess, and you're and canvas can be updated from 463 00:31:00.400 --> 00:31:03.720 a worker thread off of the main thread, which is 464 00:31:03.759 --> 00:31:06.200 not something you can do with the regular browser dome. 465 00:31:07.319 --> 00:31:15.119 So you're able to draw into this wholly separate user 466 00:31:15.160 --> 00:31:21.680 interface GPU layer without impacting the rendering time of the 467 00:31:21.799 --> 00:31:26.720 actual browser at all. That's very very cool. 468 00:31:27.839 --> 00:31:30.279 There's a little bit overhead because we have to still 469 00:31:30.960 --> 00:31:34.559 send the data over to the worker thread, but from 470 00:31:34.559 --> 00:31:37.799 our testing it's pretty minimal. It doesn't affect like the 471 00:31:38.000 --> 00:31:39.279 standard metrics as much. 472 00:31:40.799 --> 00:31:45.799 I understand, but for example, you still need to for example, 473 00:31:45.880 --> 00:31:49.960 get the rectangle the actual rectangles on the display of 474 00:31:51.920 --> 00:31:57.160 the dome elements, and if they there scroll, you kind 475 00:31:57.200 --> 00:31:59.640 of need to move the rectangle along with them. Or 476 00:31:59.640 --> 00:32:03.880 something or things along that line. Correct, So that does 477 00:32:03.960 --> 00:32:06.640 still take a little bit of overhead in terms of 478 00:32:07.519 --> 00:32:11.400 work on the main thread. But basically you're just firing 479 00:32:11.519 --> 00:32:15.079 that throwing that over into that worker and it does 480 00:32:15.119 --> 00:32:20.960 the heavy lifting exactly. Yeah, have you measured the impact 481 00:32:21.079 --> 00:32:24.480 the performance impact that having reacts can on the site 482 00:32:24.519 --> 00:32:28.359 actually has, because that's that's indeed a real problem that 483 00:32:28.599 --> 00:32:32.480 you know, it's kind of like quantum physics, where you're 484 00:32:32.519 --> 00:32:37.440 measuring things can actually impact the behavior of the application. 485 00:32:37.720 --> 00:32:41.000 Like I recently saw a tweet about somebody saying that 486 00:32:41.480 --> 00:32:44.519 he had a bug in there in his code. He 487 00:32:44.599 --> 00:32:48.920 added the log, the bug went away, he removed the log, 488 00:32:49.079 --> 00:32:52.920 the bug came back. So sometimes even the act of 489 00:32:53.039 --> 00:32:57.039 measuring can really impact the performance and behavior of the 490 00:32:57.119 --> 00:33:01.480 of an application. So how how did you actually verify 491 00:33:01.680 --> 00:33:04.160 that you have hardly any impact on the run time 492 00:33:04.200 --> 00:33:05.359 of the application itself? 493 00:33:06.519 --> 00:33:10.839 Measuring here, Like it's like not really a good way 494 00:33:10.880 --> 00:33:14.559 to figure out the overhead. Like, basically we run on dev, 495 00:33:14.680 --> 00:33:16.880 which means they're using development builds, which is not the 496 00:33:16.920 --> 00:33:18.920 same as a production build. So development bills will likely 497 00:33:19.039 --> 00:33:25.039 be slower than production builds on a basic app. It's around, 498 00:33:25.200 --> 00:33:28.200 it's like less than one percent. At more heavy apps 499 00:33:28.480 --> 00:33:30.920 still less than one percent. But like in reality, we 500 00:33:31.680 --> 00:33:33.640 like you can you have to like measure on like 501 00:33:33.640 --> 00:33:37.759 a large scale applications and actually on the correct build 502 00:33:38.000 --> 00:33:41.039 of the app to understand the overhead. Right now, it 503 00:33:41.079 --> 00:33:45.799 doesn't matter too much, but like as I said, like 504 00:33:45.799 --> 00:33:48.319 it maybe for some edge case it might be much 505 00:33:48.319 --> 00:33:51.920 more question. 506 00:33:53.440 --> 00:33:57.880 As you said, you're using the same APIs that React 507 00:33:58.240 --> 00:34:04.440 dev tools uses internally, in fact, by the way undocumented APIs. 508 00:34:04.319 --> 00:34:11.760 As I understand, what is the advantage then of using 509 00:34:11.920 --> 00:34:16.280 React scan over just using the React's own developer tools 510 00:34:16.320 --> 00:34:19.119 for

essentially the same purpose because they also have a 511 00:34:19.199 --> 00:34:23.519 performance view in there. If you install the Chrome extension 512 00:34:23.679 --> 00:34:26.679 for the React Developer tools, for example, you get a 513 00:34:26.719 --> 00:34:31.840 performance tab, a React performance tab in the developer tools. 514 00:34:31.920 --> 00:34:36.039 So what's the advantage of using a React scan over 515 00:34:36.239 --> 00:34:40.719 that capability that React provides themselves out of the box. 516 00:34:41.679 --> 00:34:44.400 Yeah, Like I view React Depth tools as like the 517 00:34:44.519 --> 00:34:48.639 endgame of debt tools. Like it's it's a great version. 518 00:34:48.960 --> 00:34:51.519 There's obviously improvements that can be made, but it's like 519 00:34:51.880 --> 00:34:54.400 the best React depth tools React. 520 00:34:54.719 --> 00:34:54.880 Right. 521 00:34:56.239 --> 00:35:00.199 The problem is, like you need kind of like a there, 522 00:35:00.239 --> 00:35:03.880 there's there's like a very low like you have to 523 00:35:03.880 --> 00:35:06.760 be decently skilled at using React deaf tools or crumb 524 00:35:06.760 --> 00:35:09.239 debt tools in order to use those depth tools, and 525 00:35:09.280 --> 00:35:12.880 most people don't really know how to do it. React 526 00:35:12.920 --> 00:35:16.119 scin is a more accessible version of it, specifically for 527 00:35:16.480 --> 00:35:21.480 rendering and performance app performance issues inside your React app. 528 00:35:21.800 --> 00:35:25.599 React deptols is more general, more advanced depth tools for 529 00:35:26.320 --> 00:35:32.920 interacting with your app. Uh yeah, I use React and 530 00:35:32.960 --> 00:35:35.840 React depth tools. Uh for my use case. 531 00:35:36.880 --> 00:35:40.639 Oh okay, cool. So when I used React scan is 532 00:35:40.679 --> 00:35:43.960 it Does it even require the depv tools to be open? 533 00:35:44.239 --> 00:35:48.440 Or do I just see everything on the browsers display. 534 00:35:48.079 --> 00:35:52.280 Itself undevelopment in development, you just drop a script tag 535 00:35:52.440 --> 00:35:55.199 into your like head tags and then it should. 536 00:35:55.000 --> 00:35:58.280 Work and you don't need to open depth tools at all. 537 00:35:58.639 --> 00:36:01.280 No, no, yeah, you just have it. It just runs 538 00:36:01.639 --> 00:36:02.199 you know where. 539 00:36:02.239 --> 00:36:08.599 That's potentially a very significant advantage on mobile devices. The 540 00:36:08.760 --> 00:36:11.800 fact that I can just drop in a script tag 541 00:36:12.360 --> 00:36:17.880 and see the issues on the browser screen itself is 542 00:36:18.079 --> 00:36:24.960 a big advantage in terms of identifying such issues versus 543 00:36:25.000 --> 00:36:30.719 having to attach the phone a physical phone via a 544 00:36:30.760 --> 00:36:34.920 physical wire to a mac or PC in order to 545 00:36:35.440 --> 00:36:38.679 open a remote debugger and then

debug everything that way. 546 00:36:39.119 --> 00:36:42.119 It's a much more convoluted process. If I can just 547 00:36:42.239 --> 00:36:45.559 see all the problems directly on my mobile screen, that's 548 00:36:45.559 --> 00:36:47.639 a huge advantage from my perspective. 549 00:36:48.400 --> 00:36:49.920 Yeah, that seems like a really good use case. 550 00:36:51.639 --> 00:36:55.039 Now do you only show the squares with the colors 551 00:36:55.119 --> 00:36:57.440 or do you sew additional information there? 552 00:36:58.199 --> 00:37:02.199 So induce us shows some additional information on the screen itself. 553 00:37:02.239 --> 00:37:04.760 So each rectangle will have a little label on it 554 00:37:04.960 --> 00:37:07.679 showing the component name and also how many times renders 555 00:37:07.719 --> 00:37:10.639 and how much time it took. You can also there's 556 00:37:10.679 --> 00:37:15.519 like a in browser toolbar. You can inspect any component 557 00:37:15.599 --> 00:37:18.639 or render to see when it renders. You can replay them. 558 00:37:19.039 --> 00:37:21.119 You can see what props change, what state changed, where 559 00:37:21.159 --> 00:37:24.360 context changed, and you can just figure out exactly what 560 00:37:24.400 --> 00:37:29.119 are the props or attributes or information about the React 561 00:37:29.119 --> 00:37:31.800 component that are causing the problematic performance. 562 00:37:33.079 --> 00:37:37.559 Wow, that's really really cool. By the way, when I 563 00:37:37.719 --> 00:37:44.639 drop in that script tag, does it automatically enable this 564 00:37:45.480 --> 00:37:47.920 you AI, or do I also need to do something 565 00:37:47.960 --> 00:37:50.719 in the browser itself to enable it, Because I'm thinking 566 00:37:51.360 --> 00:37:55.880 that in some cases people will want to have that 567 00:37:57.280 --> 00:38:00.239 script tag be present, you know, all the way is 568 00:38:00.280 --> 00:38:04.719 but not have all the users seeing those rectangles. 569 00:38:05.320 --> 00:38:08.760 Yeah, by default it only runs in developments. We do 570 00:38:08.920 --> 00:38:13.440 offer like programmatic off and on APIs. So like companies 571 00:38:13.440 --> 00:38:17.400 like Notion or Shopify, what they do is they are sorry, yeah, 572 00:38:17.440 --> 00:38:22.400 Shopify Notion, they have an internal to bar and basically 573 00:38:22.880 --> 00:38:25.480 you can click like turn React scan on and it 574 00:38:25.519 --> 00:38:29.079 turns the and opens the React skan overlay and two bar. 575 00:38:30.920 --> 00:38:35.440 What you might want to do as well is maybe 576 00:38:35.639 --> 00:38:39.639 add the support for a special URL parameter m HM, 577 00:38:40.280 --> 00:38:43.639 so that you could turn it on or off using 578 00:38:43.880 --> 00:38:48.559 a URL parameter that you know doesn't hopefully doesn't conflict 579 00:38:48.599 --> 00:38:52.360 with anybody's URL parameter, but that would make it especially easy, 580 00:38:52.440 --> 00:38:55.880 especially on mobile. I thinking that that would be very useful. 581 00:38:56.480 --> 00:39:00.559 We did similar things at Wix where we added special 582 00:39:00.599 --> 00:39:04.719 debugging capabilities into Wix websites, but they were only enabled 583 00:39:04.800 --> 00:39:12.840 with a very specialized, well not document not externally documented 584 00:39:13.440 --> 00:39:17.199 URL parameter, obviously nothing that could actually break a website. 585 00:39:17.280 --> 00:39:20.800 You know, you need to be careful because their potential 586 00:39:23.039 --> 00:39:27.119 security issues around that. You know, somebody could send the 587 00:39:27.239 --> 00:39:30.320 link with that URL parameter to somebody and then they 588 00:39:30.360 --> 00:39:33.599 would see the red lines and then they would get 589 00:39:33.639 --> 00:39:36.280 all freaked out because they would think something is wrong 590 00:39:36.440 --> 00:39:40.039 or something along these lines. But in general, I think 591 00:39:40.119 --> 00:39:44.400 that this can be a useful feature. 592 00:39:45.199 --> 00:39:45.880 Yeah, that's awesome. 593 00:39:46.280 --> 00:39:49.920 Right after this podcast, I'm glad that I can help 594 00:39:50.000 --> 00:39:54.599 make the product better. I also saw various demos that 595 00:39:54.639 --> 00:39:57.840 you were showing about all sorts of ways to graph 596 00:39:58.280 --> 00:40:04.320 the component hierarchies in the React application. Is that also 597 00:40:04.440 --> 00:40:05.480 part of the same thing. 598 00:40:06.519 --> 00:40:09.159 We haven't shipped that, but we're just playing around with 599 00:40:09.679 --> 00:40:14.239 what visualizations would work. So, like for context, I was 600 00:40:14.239 --> 00:40:17.480 working in this really large enterprise e commerce app and 601 00:40:18.199 --> 00:40:21.519 they had a bunch of components depending on the same context. 602 00:40:21.599 --> 00:40:23.960 But it was really commolluted, right because they were like 603 00:40:24.119 --> 00:40:26.920 nested hooks. There was nested components, Like a bunch of 604 00:40:26.920 --> 00:40:30.440 stuff was re rendering. I didn't know why. So I 605 00:40:30.480 --> 00:40:33.800 spent like ten hours just on tl draw graphing out 606 00:40:33.920 --> 00:40:36.360 the entire code base from the route that. 607 00:40:36.360 --> 00:40:37.039 Was re rendering. 608 00:40:38.480 --> 00:40:40.079 And I was like, why the why the heck am 609 00:40:40.119 --> 00:40:42.360 I doing this? Like like this is like so much 610 00:40:42.440 --> 00:40:46.119 work just to figure out why all these components are rendering. 611 00:40:47.000 --> 00:40:49.039 One thing we want to do this, dude, try is 612 00:40:49.239 --> 00:40:52.360 doing this automatically? Like, can we graph out the component 613 00:40:52.400 --> 00:40:55.440 tree and also the hooks tree and show where the 614 00:40:55.480 --> 00:40:59.360 source of the problem

is most like re rendering issues, 615 00:40:59.400 --> 00:41:01.800 like they can be caused by a higher component or 616 00:41:01.840 --> 00:41:05.679 a context, but usually they're systemic, right, Like, it's usually 617 00:41:05.719 --> 00:41:09.079 like one context causing all these components to rerender, and 618 00:41:09.119 --> 00:41:13.000 all these components have faulty implementations that cause this performance issue. 619 00:41:14.519 --> 00:41:17.679 So we're trying it. We're trying some visualizations to help exces. 620 00:41:19.280 --> 00:41:23.840 So we have a user from LinkedIn to asked, what 621 00:41:24.079 --> 00:41:27.039 is the business model for the react scan project? Is 622 00:41:27.079 --> 00:41:30.239 there a cost to using react scan? I'll fill in 623 00:41:30.280 --> 00:41:33.400 the blank. Is it open source? Is it free? What's 624 00:41:33.440 --> 00:41:37.320 what's your business model around this tool? Are is it 625 00:41:37.360 --> 00:41:40.039 already released? Is it beta? Where are we at? 626 00:41:40.239 --> 00:41:43.239 Yes, it's it's not one point oh, but you can 627 00:41:43.320 --> 00:41:46.000 it's stable, you can try in your app. It's free, 628 00:41:46.039 --> 00:41:48.079 open source, you can copy the code, you can fork it, 629 00:41:48.119 --> 00:41:50.440 you can do anything with it. If your company requires 630 00:41:50.719 --> 00:41:52.760 it's a host on our internal package. You can do 631 00:41:52.760 --> 00:41:56.000 whatever you want. The way we make money is through 632 00:41:56.119 --> 00:41:59.480 monitoring and observability. So we have a different product that 633 00:41:59.679 --> 00:42:06.280 uses is React scan on in like et or staging environments, 634 00:42:06.480 --> 00:42:08.880 so you can run your playwright test. We figure out 635 00:42:08.920 --> 00:42:11.639 the performance scores of these playwright test and tell you 636 00:42:11.679 --> 00:42:15.400 whether the performance increase or decreased. This is a This 637 00:42:15.480 --> 00:42:18.679 is a real problem because like most observability tools like 638 00:42:19.559 --> 00:42:22.519 Century data DOT, they're really confusing, right, you have to 639 00:42:22.599 --> 00:42:26.440 like read profiles, the graphs are somewhat like we'd like, 640 00:42:27.079 --> 00:42:28.880 and it doesn't really tell me like what is the 641 00:42:28.960 --> 00:42:31.360 root cause of the problem. We're trying to solve this. 642 00:42:31.400 --> 00:42:33.480 We're trying to do this specifically solve this for React. 643 00:42:34.920 --> 00:42:39.960 So it's it's essentially a performance budget tool for React applications. 644 00:42:40.199 --> 00:42:40.880 Yeah, exactly. 645 00:42:41.719 --> 00:42:44.360 By the way, for again, performance budget is something that 646 00:42:44.400 --> 00:42:47.119 we mentioned in previous episodes for those of you don't 647 00:42:47.119 --> 00:42:50.360 remember or don't know what it is. A performance budget 648 00:42:50.440 --> 00:42:56.719 is a way to say, like, specify how much how 649 00:42:56.800 --> 00:43:00.800 performance I expect my application to be, and then during 650 00:43:00.960 --> 00:43:07.599 the testing process in your CICD flow, you can measure 651 00:43:07.800 --> 00:43:13.599 the performance of the latest build, compare it to your 652 00:43:13.719 --> 00:43:17.320 budget limits, and if you exceed your budget limits, you 653 00:43:17.440 --> 00:43:20.119 essentially break the build like you would for any other bug. 654 00:43:20.599 --> 00:43:22.960 And then the only way in which you can release 655 00:43:23.000 --> 00:43:27.199 it is either fix the performance issue that you're under 656 00:43:27.239 --> 00:43:31.519 budget again, or unfortunately, in some cases, you might need 657 00:43:31.559 --> 00:43:33.920 to increase the budget because maybe you just made the 658 00:43:34.000 --> 00:43:37.440 UI more complicated and sophisticated, and therefore it's a legitimate 659 00:43:38.119 --> 00:43:43.880 decision to make. But you're doing it with full awareness 660 00:43:43.880 --> 00:43:46.679 of what you're changing. It's not just something that happens 661 00:43:46.760 --> 00:43:48.960 and you're not even aware that it's going on, that 662 00:43:48.960 --> 00:43:53.519 your application is becoming slower. So you're building a performance 663 00:43:53.559 --> 00:43:58.519 budgeting tool that's focused on React application. It's not just 664 00:43:58.639 --> 00:44:02.199 working at the co word vital is level. It's focused 665 00:44:02.239 --> 00:44:06.159 on React and it helps you understand how you React 666 00:44:06.239 --> 00:44:09.280 application is actually working in terms of performance, and if 667 00:44:09.679 --> 00:44:12.280 you exceed your budget, not only does it break your build, 668 00:44:12.360 --> 00:44:15.639 but it also tells you where the problem is likely act. 669 00:44:17.000 --> 00:44:21.960 We do also do quero vital So basically, the data 670 00:44:22.039 --> 00:44:26.079 hierarchy is interactions. So if interaction becomes slower or your 671 00:44:26.079 --> 00:44:28.760 playwright test that's a problem, then we go a little 672 00:44:28.760 --> 00:44:31.440 bit deeper out like if an interaction is slow, what 673 00:44:31.480 --> 00:44:35.360 components may have caused that? Or what components underwhere may 674 00:44:35.360 --> 00:44:38.079 have caused that? And then potentially like down to the render, 675 00:44:38.320 --> 00:44:41.599 like what props, context or state may have changed. 676 00:44:43.800 --> 00:44:47.039 Now, what I'm thinking that might be really useful in 677 00:44:47.079 --> 00:44:51.239 this context is something although off the top, I'm not 678 00:44:51.440 --> 00:44:54.199 exactly it's more of a vague idea that I have 679 00:44:54.440 --> 00:44:57.639 rather than a plan. But you know, one way in 680 00:44:57.679 --> 00:45:04.760 which REACT performance is improved in at least in perceived

performance, 681 00:45:04.800 --> 00:45:13.119 if not actual performance, is using suspense by deferring rendering 682 00:45:13.199 --> 00:45:19.360 of certain non urgent UI components. Maybe they are maybe 683 00:45:19.440 --> 00:45:24.239 they're outside the visual display area, or maybe they show 684 00:45:24.719 --> 00:45:30.760 lower important information or stuff like that. How do you 685 00:45:31.119 --> 00:45:34.280 handle those? Can you recommend to me that this thing 686 00:45:34.400 --> 00:45:38.760 should be should use suspense or stuff like that? Is 687 00:45:38.800 --> 00:45:41.119 that something that you're thinking about or looking at? 688 00:45:41.960 --> 00:45:44.440 Yeah, of course that's all on scope basically. 689 00:45:46.760 --> 00:45:52.920 Cool, and so any like hints about what you're thinking 690 00:45:52.920 --> 00:45:53.960 about doing in this. 691 00:45:54.000 --> 00:46:00.719 Context specifically, For so, there's a couple applications like things 692 00:46:00.719 --> 00:46:04.320 outside the viewport well and it if it renders, we 693 00:46:04.559 --> 00:46:09.599 mark that as like an unnecessary render. M hmm, like there, 694 00:46:09.639 --> 00:46:11.920 I mean, like obviously there are different solutions here, like first, 695 00:46:11.920 --> 00:46:14.480 maybe don't render it, or maybe there are some like 696 00:46:14.559 --> 00:46:19.000 hacky solutions for like partial hydration, like don't hydrate unless 697 00:46:19.000 --> 00:46:24.400 it's viewed, or like suspense as you're saying, we don't 698 00:46:24.480 --> 00:46:28.360 do recommendations yet, but we do detect the problems itself 699 00:46:28.400 --> 00:46:28.760 right now. 700 00:46:29.760 --> 00:46:35.480 Okay, So when you're doing when you're doing the that 701 00:46:35.679 --> 00:46:41.559 rectangle highlight, if the rectangle is wholly outside the visual 702 00:46:42.360 --> 00:46:46.480 the visual viewport, then it gets kind of flagged and 703 00:46:46.599 --> 00:46:50.440 logged that, hey, this was an unnecessary render. You should 704 00:46:50.519 --> 00:46:53.280 be doing something about avoiding avoiding. 705 00:46:52.840 --> 00:46:56.639 That exactly, Yeah. 706 00:46:55.559 --> 00:47:00.199 Or postponing that or so something along these lines. That's 707 00:47:00.440 --> 00:47:05.119 very very nice. So you said that you're using both 708 00:47:05.360 --> 00:47:12.719 React scan together with uh the with the React dev tools. 709 00:47:13.079 --> 00:47:18.199 What where do you focus? What information do you get where? 710 00:47:19.159 --> 00:47:22.679 Like what's the benefit of using them both together? Yeah? 711 00:47:22.679 --> 00:47:25.920 Anywhere from like skill level zero to skill level maybe 712 00:47:26.079 --> 00:47:28.719 seventy or eighty percent, which is basically like looking at 713 00:47:28.719 --> 00:47:31.719 the renders where they occur inspecting components with props change 714 00:47:31.800 --> 00:47:35.679 or components change. I use React scan for for React 715 00:47:35.719 --> 00:47:38.800 deb tools, I use the profiler component so like it 716 00:47:38.840 --> 00:47:42.199 shows like a timeline of like what functions ran. I 717 00:47:42.199 --> 00:47:45.760 also use the Chrome dev tools profiler, and then sometimes 718 00:47:45.760 --> 00:47:49.519 I use the componentry provided within React obt tools. Like obviously, 719 00:47:49.559 --> 00:47:51.800 if React debt tools works for you, you should use it. 720 00:47:52.239 --> 00:47:55.119 I recommend giving reactscan a try. If it works better 721 00:47:55.119 --> 00:47:57.320 for certain use cases, you should use it for use case. 722 00:47:57.320 --> 00:47:58.519 If it doesn't, then then don't. 723 00:47:59.559 --> 00:48:02.239 One more thing that you might try to do, assuming 724 00:48:02.280 --> 00:48:04.960 it's not too complicated or doesn't have too high over 725 00:48:05.039 --> 00:48:08.159 it in and of itself, is that if the user 726 00:48:08.559 --> 00:48:13.480 hovers on top of one of those tooltips then that 727 00:48:13.639 --> 00:48:17.440 you render on the canvas, then you can could display 728 00:48:17.480 --> 00:48:21.119 additional information like what caused the latest surrender or stuff 729 00:48:21.159 --> 00:48:26.559 like that, things that wouldn't fit inside the tooltip of itself. Again, 730 00:48:26.639 --> 00:48:31.079 anything that can save me the need to have to 731 00:48:31.199 --> 00:48:34.039 open Chrome dev tools and go back in history would 732 00:48:34.079 --> 00:48:38.239 be very beneficial. Obviously a problem with hovering is that 733 00:48:38.280 --> 00:48:41.159 it doesn't actually work on mobile devices, or maybe a 734 00:48:41.199 --> 00:48:44.599 click on those you know, tapping on the tooltip or 735 00:48:44.639 --> 00:48:49.360 something along these lines that could be that could be useful. Again, 736 00:48:49.519 --> 00:48:54.000 especially because on mobile devices, accessing DEPV tools becomes a 737 00:48:54.039 --> 00:48:57.400 lot more challenging. So anything you can show on the 738 00:48:57.440 --> 00:49:00.519 mobile display itself is very ben official. 739 00:49:01.079 --> 00:49:05.760 That's an amazing idea. Yeah, perfect, I'm just getting this 740 00:49:05.800 --> 00:49:06.679 is like a user interview. 741 00:49:08.719 --> 00:49:11.639 Well, you know, performance is my jam, so you know 742 00:49:12.360 --> 00:49:15.559 I've been doing this for a long time, longer I 743 00:49:15.599 --> 00:49:18.880 wouldn't say longer than you've been alive, but starting to 744 00:49:18.960 --> 00:49:25.320 come on that. So, yeah, anything else you want to 745 00:49:25.360 --> 00:49:28.280 tell us about your tools or things that you're looking 746 00:49:28.320 --> 00:49:30.519 at doing, or things that you want the listeners to 747 00:49:30.559 --> 00:49:31.000 know about. 748 00:49:32.159 --> 00:49:34.639 Yeah, I mean, if there's one thing you should listen 749 00:49:35.440

--> 00:49:39.840 do is performance matters a lot, like probably more than 750 00:49:39.880 --> 00:49:43.840 you expect. And even if it I mean, like even 751 00:49:43.880 --> 00:49:46.519 if it doesn't matter your company, like people leadership doesn't 752 00:49:46.519 --> 00:49:49.920 really care, you should try at least see if it 753 00:49:50.000 --> 00:49:53.360 maybe will improve some metric for users or improve your sales. 754 00:49:53.679 --> 00:49:57.119 If you're just an individual user, try learning how performance works, 755 00:49:57.239 --> 00:50:04.519 upskill yourself performance. Like my experience, there are not that 756 00:50:04.599 --> 00:50:08.320 many performance experts, and there's a lot of need for 757 00:50:08.360 --> 00:50:12.719 performance experts, and so from a job opportunity perspective, there's 758 00:50:12.840 --> 00:50:17.519 also there's an opportunity there, So learned performance har we 759 00:50:17.679 --> 00:50:23.800 x scan if you want to. And yeah, in this context. 760 00:50:23.800 --> 00:50:28.400 By the way, there's the actual excellent web dot dev 761 00:50:28.440 --> 00:50:33.119 website which is actually run by the Google Chrome DevRel 762 00:50:33.199 --> 00:50:36.800 team I think, and they have a section there called 763 00:50:36.960 --> 00:50:43.400 case studies Case Studies on Web dot Dev, which basically 764 00:50:43.480 --> 00:50:47.880 is just this huge list of case studies of companies 765 00:50:47.920 --> 00:50:51.119 that improve their performance and got a huge boost to 766 00:50:51.239 --> 00:50:54.519 their sales or bottom line or whatever as a result. 767 00:50:55.119 --> 00:50:58.239 So if your company doesn't care about performance and you 768 00:50:58.320 --> 00:51:02.360 need to convince management that performance is actually important, then 769 00:51:02.480 --> 00:51:06.679 web dot dev Slash case studies is a great resource 770 00:51:06.719 --> 00:51:10.159 to use in this context. And I totally agree with 771 00:51:10.199 --> 00:51:14.719 you that having good performance is a game changer in 772 00:51:14.760 --> 00:51:19.360 many cases. It's the whole difference between an application that's 773 00:51:19.719 --> 00:51:23.920 pleasant to use, that's engaging, versus one that you hate 774 00:51:24.039 --> 00:51:27.480 using because it's janky and unresponsive. 775 00:51:29.199 --> 00:51:29.599 For sure. 776 00:51:29.840 --> 00:51:37.880 Yeah, and it's also an accessibility thing, and it's about 777 00:51:38.000 --> 00:51:41.119 enabling people who might otherwise not be able to use 778 00:51:41.119 --> 00:51:45.159 your application to actually use it and benefit from it. 779 00:51:45.840 --> 00:51:50.320 Because again, like you said, if your application was written 780 00:51:50.920 --> 00:51:55.639 by people with really high end devices fast max fast iPhones, 781 00:51:56.679 --> 00:51:59.880 and they never bother to check on lower end device 782 00:52:00.159 --> 00:52:03.599 is or they just don't care about performance because it's 783 00:52:03.639 --> 00:52:07.079 good enough on their own devices, they not may not 784 00:52:07.199 --> 00:52:10.159 be aware that people on lower end devices just found 785 00:52:10.320 --> 00:52:12.280 find their application wholly unusable. 786 00:52:12.920 --> 00:52:15.679 Yeah, exactly. And you'd be surprised the amount of e 787 00:52:15.719 --> 00:52:20.280 commerce companies where performance actually matters to sales that don't monitor, 788 00:52:20.400 --> 00:52:23.599 monitor performance or care that much, and so what happens 789 00:52:23.719 --> 00:52:26.360 is they are literally losing out on like seven to 790 00:52:26.400 --> 00:52:28.719 eight figures sales every year. 791 00:52:30.159 --> 00:52:34.760 By the way, again speaking about React, we had Rick 792 00:52:34.840 --> 00:52:38.679 Wickskomi from Google on our show or a few years back, 793 00:52:38.760 --> 00:52:41.480 and he runs this great service. I don't know if 794 00:52:41.519 --> 00:52:46.119 you're familiar with it. It's h it's a Chrome User Experience 795 00:52:46.199 --> 00:52:50.679 Report or CRUs. Yes, uh. And they have this website 796 00:52:50.719 --> 00:52:56.280 where you can actually see the performance graphs by technology. 797 00:52:56.760 --> 00:53:01.760 So Google literally grabs performance in information from your browser 798 00:53:02.239 --> 00:53:06.280 unless you opt out from your Chrome browser, and they 799 00:53:06.360 --> 00:53:09.360 upload it into their database anonymously of course at least 800 00:53:09.360 --> 00:53:12.519 so they say. And then they and there they run 801 00:53:12.559 --> 00:53:16.280 all sorts of analyzes on it, including which technologies it uses. 802 00:53:17.079 --> 00:53:21.119 And that makes it possible, for example, to see how 803 00:53:21.159 --> 00:53:25.559 good REACT websites in general are in terms of performance. 804 00:53:26.079 --> 00:53:31.440 So we mentioned the three co ed vitals. A A 805 00:53:31.559 --> 00:53:35.039 site is considered to have good performance if it has 806 00:53:35.119 --> 00:53:38.159 if it's good for all three cowed vitals. That means 807 00:53:38.199 --> 00:53:43.199 that it's fast enough at the seventy fifth percentile for LCP, 808 00:53:43.400 --> 00:53:47.280 for CLS, and for IMP for example, LCP needs to 809 00:53:47.280 --> 00:53:50.199 be faster than two and a half seconds at the 810 00:53:50.199 --> 00:53:54.679 seventy fifth percentile. As I recall, and it turns out 811 00:53:54.840 --> 00:53:59.679 that if you look at React websites, can you guess 812 00:54:00.159 --> 00:54:04.760 what percentage of React websites in the totality of all 813 00:54:04.800 --> 00:54:08.920 React websites actually get good COVID vitals. 814 00:54:10.679 --> 00:54:14.079 If I were to guess, maybe like ten, No. 815 00:54:14.280 --> 00:54:19.039 You're being overly harsh. It turns out, well, it used 816 00:54:19.079 --> 00:54:21.239 to be that way,

but it turns out that the 817 00:54:21.320 --> 00:54:27.239 browser makers have been doing a phenomenal job of improving 818 00:54:27.400 --> 00:54:31.360 the performance of the platform itself. So even though React 819 00:54:31.400 --> 00:54:35.320 websites in and of themselves may not have improved that much, 820 00:54:35.920 --> 00:54:39.039 just because the browsers have been getting better and faster 821 00:54:39.119 --> 00:54:43.960 and more sophisticated, then the React scores have gone up. 822 00:54:44.119 --> 00:54:48.280 In fact, all websites scores have gone up amazing. So 823 00:54:50.639 --> 00:54:55.119 if I look, so, we were at twenty percent on 824 00:54:55.320 --> 00:55:01.119 React websites back in twenty twenty one. So in April 825 00:55:01.159 --> 00:55:06.840 twenty twenty one we cross the twenty percent threshold. Now 826 00:55:07.320 --> 00:55:12.960 React websites are forty one percent have good coed vitals. 827 00:55:13.440 --> 00:55:18.239 That's phenomenal. That means that almost well fifty nine percent don't, 828 00:55:18.639 --> 00:55:22.800 which is the majority of React websites, which is truly unfortunate. 829 00:55:23.119 --> 00:55:26.760 By the way, if we compare to other technologies, WordPress 830 00:55:27.719 --> 00:55:34.760 slightly ahead of React. So people building WordPress websites, they 831 00:55:34.840 --> 00:55:37.239 are at forty three percent, so they are two percent 832 00:55:37.440 --> 00:55:41.599 better than React. So you're thinking you're a hot shot 833 00:55:41.639 --> 00:55:44.800 React developer, and I'm talking to our listeners, there's a 834 00:55:44.840 --> 00:55:48.760 good chance that the WordPress website built by some web 835 00:55:48.800 --> 00:55:54.599 designer has better performance than your sophisticated React website. And 836 00:55:54.679 --> 00:55:57.559 if I'm looking at other technologies like you mentioned Shopify, 837 00:55:58.199 --> 00:56:03.599 Shopify is at seventy six percent and wis for example, 838 00:56:03.639 --> 00:56:09.079 is at sixty five percent. So seventy six percent of 839 00:56:09.159 --> 00:56:12.920 all shops of all the Shopify websites have good coed 840 00:56:13.000 --> 00:56:18.360 vitals and that's almost double React. That's pretty that's pretty 841 00:56:19.559 --> 00:56:27.960 unfortunate from my perspective. Yeah, and hopefully with hopefully, with 842 00:56:28.119 --> 00:56:32.559 tools like React scan, people can make their React websites 843 00:56:33.559 --> 00:56:37.199 more like load faster, be more responsive, and generally be 844 00:56:37.800 --> 00:56:41.079 more pleasant and more accessible to use. By the way, 845 00:56:41.519 --> 00:56:45.079 have you also thought about doing things related to accessibility 846 00:56:45.159 --> 00:56:49.639 in your application or you for now focusing only on performance? 847 00:56:51.480 --> 00:56:54.079 For now on performance, but that'd be a cool extension 848 00:56:54.119 --> 00:56:57.239 if there

if there is enough of a need for. 849 00:56:57.199 --> 00:57:02.159 That, I think there there should be. But you know, 850 00:57:02.199 --> 00:57:07.639 it's your business. So if people want to try out 851 00:57:07.760 --> 00:57:10.719 react scan, like you said, it's open source, it's free 852 00:57:10.719 --> 00:57:13.039 to use, how can they go about it? And if 853 00:57:13.079 --> 00:57:17.239 they want to try out your more sophisticated tools for 854 00:57:17.400 --> 00:57:19.960 the c I c D pipeline, how should they go 855 00:57:20.039 --> 00:57:20.559 about it? 856 00:57:21.079 --> 00:57:23.360 Yeah, you can just got to react scan dot com. 857 00:57:23.440 --> 00:57:26.679 Let's react scan dot com or just look up react 858 00:57:26.679 --> 00:57:31.360 scan and google there there's research. It tells you how 859 00:57:31.400 --> 00:57:33.440 to install the basic react scan and we have another 860 00:57:33.480 --> 00:57:35.920 page called monitoring, which should be on the website. You 861 00:57:35.920 --> 00:57:38.360 can click on and then try the demo and then 862 00:57:38.400 --> 00:57:41.800 add your website yourself. It should. React scan takes lesson 863 00:57:41.920 --> 00:57:45.920 a minute to set up. Our minoring service takes also 864 00:57:46.079 --> 00:57:47.400 probably less than five minutes. 865 00:57:49.480 --> 00:57:51.800 Is it also possible to add it to a page 866 00:57:51.880 --> 00:57:54.360 using NPM or is it just via script tag? 867 00:57:55.119 --> 00:57:57.239 NPM script tag you can run to be your cl I. 868 00:57:57.440 --> 00:57:58.960 There's there's like four ways to do it. 869 00:58:01.559 --> 00:58:03.840 Anything else that you want to mention and talk about 870 00:58:03.840 --> 00:58:07.440 in this context, not at all. 871 00:58:07.480 --> 00:58:09.960 I'm just really really grateful to be a on this 872 00:58:10.039 --> 00:58:11.519 podcast and good to talk to you again, Dan. 873 00:58:12.199 --> 00:58:15.719 Yeah, same here. I love talking about performance and I 874 00:58:15.760 --> 00:58:19.480 love seeing somebody so young, so into it and making 875 00:58:19.519 --> 00:58:22.880 such an impact in this context. You know, bringing anything 876 00:58:22.920 --> 00:58:27.679 we can do to improve the situation with React is 877 00:58:28.119 --> 00:58:30.719 great in my book. I mean, at the very least 878 00:58:31.159 --> 00:58:34.239 we need to be above fifty percent. I mean, at 879 00:58:34.280 --> 00:58:38.360 the very least more than half React websites should have 880 00:58:40.400 --> 00:58:43.719 good performance. By the way, what is also surprising to 881 00:58:43.760 --> 00:58:46.480 me and even more unfortunate. Can you guess what the 882 00:58:46.559 --> 00:58:49.159 situation is with next js? 883 00:58:49.800 --> 00:58:50.800 Is it lower than React? 884 00:58:52.199 --> 00:58:55.679 Surprisingly? It is. You would expect it to be higher 885 00:58:56.519 --> 00:59:01.960 because it provides SSR and SSG,

which are great for LCP, 886 00:59:03.280 --> 00:59:06.639 but it isn't. I actually have a talk that I 887 00:59:06.719 --> 00:59:09.880 give on this topic trying to kind of analyze why 888 00:59:09.920 --> 00:59:13.480 that is. But the bottom line is that, as I said, 889 00:59:13.519 --> 00:59:17.400 with React, it's forty one percent of React websites. Our 890 00:59:17.480 --> 00:59:20.079 websites using React would be a better way of phrasing 891 00:59:20.119 --> 00:59:24.639 it have good core vitals. With NEXTGS it's only twenty 892 00:59:24.679 --> 00:59:25.280 eight percent. 893 00:59:27.039 --> 00:59:28.880 Yeah, I'll be curious why. That's interesting. 894 00:59:29.679 --> 00:59:32.760 Yeah, I'll be curious why as well. I'm guessing part 895 00:59:32.800 --> 00:59:35.159 of it is maybe having to do with the long 896 00:59:35.239 --> 00:59:41.239 tail of old NEXTGS versions, maybe not installed on VERSELL, 897 00:59:41.440 --> 00:59:46.480 maybe installed on AWS and not properly optimized. But it's 898 00:59:46.519 --> 00:59:49.079 a good but it's a good question of why that is. 899 00:59:49.159 --> 00:59:52.519 And like I said, I have several theories and I've 900 00:59:52.599 --> 00:59:56.159 even given talks on this topic. So if you're running 901 00:59:56.159 --> 00:59:58.920 a conference and you want to hear my opinion about 902 00:59:58.960 --> 01:00:03.000 why some frameworks are faster than others, then invite me 903 01:00:03.079 --> 01:00:11.559 to speak at your conference. Anyway, Okay, I think with that, 904 01:00:12.440 --> 01:00:15.719 I'll be pushing us to that final part of our episode, 905 01:00:15.800 --> 01:00:19.079 which is the picks part. I didn't give your heads 906 01:00:19.159 --> 01:00:22.480 up for it. I hope that you can't prepare. Nonetheless, 907 01:00:22.880 --> 01:00:26.679 I'll go first, so you have time to choose. Basically, 908 01:00:26.760 --> 01:00:30.519 picks is where we shout out whatever. It can be 909 01:00:30.599 --> 01:00:33.400 technical things, it can be non technical things. It can 910 01:00:33.440 --> 01:00:41.079 be your favorite movie, TV show, band, whatever book you 911 01:00:41.159 --> 01:00:49.840 still read books and and you know, or technical things 912 01:00:49.840 --> 01:00:52.039 that you want to just you know, shout out about, 913 01:00:52.480 --> 01:00:57.000 including your own. So I'll start with mine. I don't 914 01:00:57.000 --> 01:00:58.679 have a lot in the way of picks. I have 915 01:00:59.000 --> 01:01:06.519 just one. So I'm from Israel, from television Israel, obviously, 916 01:01:07.239 --> 01:01:12.519 the situation here has been really unfortunate over the past year, 917 01:01:12.960 --> 01:01:15.599 the over a year, almost a year and a half, 918 01:01:16.119 --> 01:01:18.400 with the war going on and a lot of suffering 919 01:01:18.480 --> 01:01:22.719 and loss of life. At least we got some really 920 01:01:22.800 --> 01:01:28.119 great news as yesterdays of the time

of this recording, 921 01:01:28.679 --> 01:01:33.679 where a cease fire has gone into effect, and in particular, 922 01:01:34.840 --> 01:01:40.000 three Israeli hostages were released. They were held in captivity 923 01:01:40.079 --> 01:01:46.199 by Hamas for four hundred and seventy one days. Just 924 01:01:46.280 --> 01:01:50.960 imagine being held in a tunnel underground with the threat 925 01:01:51.000 --> 01:01:54.760 of death constantly hovering over your head, with hardly any 926 01:01:54.840 --> 01:01:58.960 food and no ability to move. And some of them 927 01:01:59.400 --> 01:02:03.000 were all so victims of abuse, even sexual abuse. It's 928 01:02:03.360 --> 01:02:09.599 very distressing. So three of the hostages were released yesterday 929 01:02:09.679 --> 01:02:13.960 as part of this agreement between Israel and Hamas. Their 930 01:02:14.079 --> 01:02:27.639 names are Doron Steinbacher, Emily Damari and I should have 931 01:02:27.639 --> 01:02:31.679 come better prepared and Romy gone. Two of them were 932 01:02:31.719 --> 01:02:35.599 actually abducted from their own homes. So on October seventh, 933 01:02:35.760 --> 01:02:42.800 twenty twenty three Hamas terrorists broke into their home kidnapped 934 01:02:42.800 --> 01:02:47.440 them literally out of their beds. One of them was shot, 935 01:02:47.960 --> 01:02:51.519 she lost some fingers in her hand, and they were 936 01:02:51.559 --> 01:02:54.880 taken into Gaza and literally in their pajamas. The third 937 01:02:54.920 --> 01:02:57.960 one was kidnapped from the Nova Music festival. Again. She 938 01:02:58.119 --> 01:03:03.519 was also shot wounded and they never got medical attention 939 01:03:03.599 --> 01:03:07.400 for that. And I'm really happy that they've been finally 940 01:03:07.440 --> 01:03:12.280 being released and reunited with their families. Hopefully they'll be 941 01:03:12.400 --> 01:03:16.920 able to make a full recovery from this ordeal. Obviously 942 01:03:16.960 --> 01:03:22.960 it's not simple, but and that still leaves ninety four 943 01:03:23.039 --> 01:03:27.280 hostages Israeli hostages in Hamasa's hands. I really hope that 944 01:03:27.559 --> 01:03:32.480 the ceasefire can persist and these hostages will be released 945 01:03:32.480 --> 01:03:37.679 eventually as well, hopefully as soon as possible, And that 946 01:03:37.719 --> 01:03:40.039 would be my pick for today. It really brought joy 947 01:03:40.079 --> 01:03:44.760 to my heart yesterday when these hostages were finally released, 948 01:03:45.840 --> 01:03:48.960 and that's my pick for today. Do you have any 949 01:03:49.000 --> 01:03:49.880 picks for us? Aidan? 950 01:03:52.119 --> 01:03:56.079 I have one thing I am much less, much less important, 951 01:03:56.079 --> 01:04:01.480 but yeah, I really, I mean I need this since Algol, 952 01:04:01.559 --> 01:04:05.320 but I really like the proxy API and JavaScript. So 953 01:04:06.000 --> 01:04:10.599 basically you can wrap any object in this like proxy keyword, 954 01:04:11.000 --> 01:04:13.199 and then you can spy on any property. So if 955 01:04:13.199 --> 01:04:16.039 you access like object dot name, you know when that 956 01:04:16.360 --> 01:04:19.920 you can like programmatically know when that property is accessed. 957 01:04:20.400 --> 01:04:25.119 Oh yeah, proxy is really cool. Yeah. Basically, you take 958 01:04:25.199 --> 01:04:27.280 you do a new proxy, and you pass in the 959 01:04:27.360 --> 01:04:32.360 object you want to what to be the instrument or 960 01:04:32.519 --> 01:04:36.039 track and like you said, any access to either reader 961 01:04:36.119 --> 01:04:39.880 property from that object, write a property to that object 962 01:04:39.960 --> 01:04:43.000 can be tracked, can also be modified, by the way, 963 01:04:43.079 --> 01:04:46.599 so you can kind of it. The one thing to 964 01:04:46.639 --> 01:04:49.000 be careful with, by the way, in this context is 965 01:04:49.039 --> 01:04:50.920 that it can be used, and it was in fact 966 01:04:50.920 --> 01:04:54.760 created for that purpose to kind of break JavaScript semantics 967 01:04:54.800 --> 01:04:59.960 in a sense, because you can override the standard JavaScript 968 01:05:00.119 --> 01:05:06.800 object behavior with proxy. I've actually done exactly what you described. 969 01:05:06.840 --> 01:05:10.639 I had a problem in an application, a legacy application 970 01:05:10.719 --> 01:05:15.679 that I was trying to refactor. Some code was modifying 971 01:05:15.719 --> 01:05:18.719 a global object and I was unable to locate where 972 01:05:18.719 --> 01:05:23.159 that modification was happening. So I literally created a proxy 973 01:05:23.239 --> 01:05:26.840 around that global and put a debugger statement in the 974 01:05:26.880 --> 01:05:32.880 property set, and that way, I when the brake happened 975 01:05:32.920 --> 01:05:35.760 in the developer tools, I had the call stack and 976 01:05:35.800 --> 01:05:39.960 I could find where that operation actually happened. That was 977 01:05:41.039 --> 01:05:43.840 I felt like having a superpower when I was able 978 01:05:43.880 --> 01:05:48.519 to do that. Yeah, proxies are very powerful, by the way. 979 01:05:48.519 --> 01:05:50.199 In other use of proxies. I don't know if you 980 01:05:50.239 --> 01:05:53.920 know this, but View I think uses proxies at least 981 01:05:53.960 --> 01:05:58.360 in the development mode to implement their reactivity. 982 01:05:59.719 --> 01:06:04.719 Yeah, I think Vaultier and some other estate management too. 983 01:06:05.800 --> 01:06:08.119 Or you can use it to like for if you 984 01:06:08.119 --> 01:06:09.920 want to get fired. You can use it to prank 985 01:06:09.960 --> 01:06:10.639 or coworkers. 986 01:06:12.559 --> 01:06:14.880 Okay, now you have to tell me what did you do? 987 01:06:15.760 --> 01:06:17.760 I haven't done it, but I was thinking of replacing 988 01:06:18.039 --> 01:06:22.320 like like we have an internal library, like returning a 989 01:06:22.400 --> 01:06:26.800 proxy and having all the properties return undefined or something. Yeah, 990 01:06:27.559 --> 01:06:28.559 something super stupid. 991 01:06:29.519 --> 01:06:33.239 Yeah, okay, you know, well, boys will be boys or 992 01:06:33.360 --> 01:06:39.519 depths will be depths, I guess. Yeah. Anyway, Aiden, it's 993 01:06:39.559 --> 01:06:42.519 been really fun having you on the show. I'm really 994 01:06:42.519 --> 01:06:45.079 excited about the stuff that you're doing. I'm really happy 995 01:06:45.119 --> 01:06:48.639 whenever something comes along which makes it possible to improve 996 01:06:48.679 --> 01:06:51.679 performance on the web. We definitely need more of that, 997 01:06:53.000 --> 01:06:57.199 and it's it's amazing to see somebody so young making 998 01:06:57.239 --> 01:07:01.320 such an impact. And I hope to be hearing more 999 01:07:01.360 --> 01:07:03.320 great things from you and having you on the show 1000 01:07:03.360 --> 01:07:06.960 again to talk about more stuff that you're doing. Yep. 1001 01:07:07.480 --> 01:07:11.480 Now and now if people want to contact you about 1002 01:07:11.519 --> 01:07:15.039 you know your existing projects, more ideas for what can 1003 01:07:15.079 --> 01:07:17.760 be done and improved with these or maybe ideas for 1004 01:07:17.840 --> 01:07:20.960 future projects. What's the best way to reach out to you. 1005 01:07:21.920 --> 01:07:24.840 I'm on Twitter, Blue Skuy YouTube. Just look at my 1006 01:07:24.960 --> 01:07:26.480 name and then you can just DM me and I'll 1007 01:07:26.519 --> 01:07:26.960 answer you. 1008 01:07:27.599 --> 01:07:30.320 So it's aid and buy on all those platforms. 1009 01:07:30.800 --> 01:07:31.559 Aiden, Why Bye? 1010 01:07:31.639 --> 01:07:37.079 Yeah? Aiden? Whyby? Okay? Great? So again, Aiden, thank you 1011 01:07:37.159 --> 01:07:40.119 for coming on our show and to all our listeners, 1012 01:07:40.159 --> 01:07:45.039 thank you for joining us. And that's it for today. Bye,