WEBVTT 1 00:00:05.120 --> 00:00:09.560 Hello, everybody, Welcome to another exciting episode of JavaScript Jabber. 2 00:00:09.599 --> 00:00:11.759 I am Steve Edwards, the host with the face for 3 00:00:11.880 --> 00:00:14.439 radio and the voice for being of mine. But I'm 4 00:00:14.439 --> 00:00:17.000 still your host at least I lost the coin flip 5 00:00:17.039 --> 00:00:20.280 today with me on our panel as mister Dan Shapiir 6 00:00:20.399 --> 00:00:21.559 coming live from Tel Aviv. 7 00:00:21.600 --> 00:00:22.280 How you doing, Dan? 8 00:00:23.079 --> 00:00:25.559 Hello from Tel Aviv where we're not at what with 9 00:00:25.679 --> 00:00:26.440 a run anymore? 10 00:00:27.679 --> 00:00:31.839 Yes, the last time we had Dan on, I believe 11 00:00:31.879 --> 00:00:34.320 he had run when bomb sirens started going off. 12 00:00:34.320 --> 00:00:35.560 So hopefully that won't happen to you. 13 00:00:35.679 --> 00:00:37.640 Yeah, missiles not bombs, but. 14 00:00:37.840 --> 00:00:43.840 Sorry, yeah, but slightly different, same end result exactly. And 15 00:00:44.119 --> 00:00:46.560 our special guest today I'm going to try to get 16 00:00:46.600 --> 00:00:48.560 this right is mister Benicius de Laqua. 17 00:00:48.600 --> 00:00:49.119 How you doing? 18 00:00:49.359 --> 00:00:53.280 Did great? Yes? Doing great. I'm here from Sweden where 19 00:00:53.320 --> 00:00:56.719 we can't decide if it's hot or not this summer. 20 00:00:57.280 --> 00:01:01.799 It's like days not. What is with this shot? It 21 00:01:01.840 --> 00:01:04.879 can actually get like up to like thirty five degrees? Wow, 22 00:01:05.000 --> 00:01:06.560 that is actually pretty hot. 23 00:01:06.599 --> 00:01:08.959 That's pretty warm. That's what around one hundred farenheit something 24 00:01:09.040 --> 00:01:09.319 like that. 25 00:01:10.280 --> 00:01:13.560 Yeah, I can hear that it's quite close to here 26 00:01:13.599 --> 00:01:16.560 that Europe is undergoing like this kind of severe heat 27 00:01:16.599 --> 00:01:17.799 wave we are. 28 00:01:17.920 --> 00:01:21.400 Yeah. Yeah, Like south of Europe is quite brutal, right now, 29 00:01:21.400 --> 00:01:24.079 like up to like forty six degrees or something. 30 00:01:24.159 --> 00:01:24.439 Wow. 31 00:01:24.599 --> 00:01:26.519 Places, Wow, that's quite bad. 32 00:01:26.680 --> 00:01:27.000 Is warm? 33 00:01:27.760 --> 00:01:31.239 Yeah, and not everybody has our conditioning. I guess no, 34 00:01:31.400 --> 00:01:32.840 Europe is not built for heats. 35 00:01:32.840 --> 00:01:33.319 I'll tell this. 36 00:01:33.879 --> 00:01:37.359 Yeah all right, So what we're here to talk about 37 00:01:37.599 --> 00:01:42.439 is the confluence of performance and AI. So actually, before 38 00:01:42.439 --> 00:01:44.280 we get started, we know where you live. Why don't 39 00:01:44.319 --> 00:01:46.959 you tell us what else you do and why people 40 00:01:46.959 --> 00:01:49.280 should give you money if they should, and that kind 41 00:01:49.280 --> 00:01:49.560 of thing. 42 00:01:49.799 --> 00:01:55.280 Yes, So I am a soft engineer. I've been around 43 00:01:55.319 --> 00:01:57.439 for quite some years. As you can see from the 44 00:01:57.439 --> 00:01:59.280 white hairs around there. 45 00:02:00.079 --> 00:02:02.239 It's like a lot of the gray going to So yeah, 46 00:02:02.840 --> 00:02:03.519 I like to. 47 00:02:03.400 --> 00:02:05.719 Say white Harry is better than no here. 48 00:02:06.640 --> 00:02:07.959 Yeah yeah, yeah, yeah. 49 00:02:08.280 --> 00:02:08.960 I feel. 50 00:02:10.199 --> 00:02:12.439 I've been working for a while, I mean being around 51 00:02:12.439 --> 00:02:15.360 since like I had to ship for even like a 52 00:02:15.599 --> 00:02:20.919 four four oh wow. Yeah yeah, yeah, so I had. 53 00:02:20.800 --> 00:02:22.960 To remember those days, I. 54 00:02:23.000 --> 00:02:29.400 Tell you, focus on performance for the biggest of my career, 55 00:02:29.560 --> 00:02:31.479 Like although never had really like the title of like 56 00:02:31.520 --> 00:02:34.840 performance engineer, performance was always like the focus of my 57 00:02:34.919 --> 00:02:38.719 interest and career coming from Brazil, Central Brazil, nonetheless, where 58 00:02:38.919 --> 00:02:41.759 you know, internet speeds were never up to standards, let's 59 00:02:41.800 --> 00:02:43.560 say like that, Let's put it like that. So you know, 60 00:02:43.759 --> 00:02:46.919 ux performance front end kind of became a thing for 61 00:02:46.960 --> 00:02:49.719 me as well, more and more over time. But performance always, 62 00:02:49.719 --> 00:02:52.599 because always was a subject that I care deeply about. 63 00:02:53.080 --> 00:02:56.199 Before we continue, just I'm just curious centers, Like what 64 00:02:56.360 --> 00:02:57.120 my mouse. 65 00:02:57.719 --> 00:03:01.360 That's not actually so central Brazil zo is like token 66 00:03:01.400 --> 00:03:05.360 Chin's Brasilia, So that's that's within the center. I was 67 00:03:05.360 --> 00:03:08.879 born in the north the States, but then like my 68 00:03:09.000 --> 00:03:11.639 entire life are lived in token Chinese, which is central Brazil. 69 00:03:12.120 --> 00:03:14.439 Okay, Yeah, that's an interesting point you bring up. 70 00:03:15.000 --> 00:03:17.960 You know a lot of developers when they're developing apps, 71 00:03:18.000 --> 00:03:20.599 they get so used to their you know and formax 72 00:03:20.719 --> 00:03:25.520 on their high speed you know, fiber internet and don't 73 00:03:25.560 --> 00:03:27.719 always think about the person might be using their app 74 00:03:27.759 --> 00:03:30.120 that's in you know, three g out in the middle 75 00:03:30.159 --> 00:03:34.159 of nowhere, you know, something like that. And so yeah, 76 00:03:34.199 --> 00:03:37.120 performers like that in terms of bundle sizes for JavaScript 77 00:03:37.159 --> 00:03:39.439 and whether you need that much JavaScript, you know, that's 78 00:03:39.800 --> 00:03:42.039 books and all topics. 79 00:03:41.680 --> 00:03:44.759 Of Yeah, I'll tell you this, like for where I 80 00:03:44.800 --> 00:03:47.879 come from, the average speeds for Internet is still like, 81 00:03:48.599 --> 00:03:52.840 you know, around like fifteen megabytes, like one hundred megabytes. 82 00:03:52.879 --> 00:03:57.159 If you're like very very well off, like it's very hard. 83 00:03:57.240 --> 00:04:00.719 It's very hard to get like like a bite over. 84 00:04:01.080 --> 00:04:04.639 It's like most people live on like four G connection. 85 00:04:05.560 --> 00:04:08.520 I was actually checking out a map I would a 86 00:04:08.560 --> 00:04:12.039 world map for like five G connectivity around the world, 87 00:04:12.039 --> 00:04:15.199 and Brazil is still, like Central Brazil especially, still very 88 00:04:15.280 --> 00:04:16.839 much mostly on four G. 89 00:04:17.759 --> 00:04:20.639 So back when I was working at WIGS, WIGS has 90 00:04:20.639 --> 00:04:24.000 a pretty strong presence in South America and especially in 91 00:04:24.000 --> 00:04:28.680 Brazil and Argentina, and that was definitely a concern about 92 00:04:28.759 --> 00:04:32.680 making sure that we provided proper a good experience in 93 00:04:32.680 --> 00:04:36.279 those regions. But I want to emphasize that it's not 94 00:04:36.480 --> 00:04:41.879 just people in certain countries, it's everybody in certain situations. 95 00:04:42.199 --> 00:04:46.160 I've been in airports in various places where I'm on 96 00:04:46.199 --> 00:04:49.600 this funky data plan and I'm trying to check my 97 00:04:49.720 --> 00:04:54.160 flight on an airline website, and it's super slow because 98 00:04:54.199 --> 00:04:57.720 they're downloading this huge image of an airplane taking off 99 00:04:58.040 --> 00:05:01.040 that I have absolutely no need for, or so you 100 00:05:01.120 --> 00:05:03.839 know it, or you might be on on in a 101 00:05:03.879 --> 00:05:07.199 subway with bad reception or in an elevator or I 102 00:05:07.240 --> 00:05:11.480 don't know where, but it's this problem of connectivity. Of 103 00:05:11.600 --> 00:05:15.920 bad connectivity is something that can happen to everybody in 104 00:05:16.399 --> 00:05:19.920 certain scenarios, and very often in the scenario where you 105 00:05:20.120 --> 00:05:23.279 especially need to get at that data. 106 00:05:23.879 --> 00:05:27.439 Absolutely, yeah, absolutely, And I mean it was always at 107 00:05:27.439 --> 00:05:31.000 the forefront of like my biggest interest in concern when 108 00:05:31.000 --> 00:05:34.000 I moved to Europe, you know, now I actually like 109 00:05:34.399 --> 00:05:37.959 I became kind of like skewed towards the better end 110 00:05:38.120 --> 00:05:41.360 of connectivities. And it's ver easy to build up your biases, 111 00:05:42.000 --> 00:05:44.879 but you can be humbled very quickly when you come 112 00:05:44.920 --> 00:05:49.199 to test stuff on connectivities there are its body or 113 00:05:49.319 --> 00:05:52.120 or you know, unreliable. So one of the things that 114 00:05:52.160 --> 00:05:55.399 I always care about and drove like used to drive 115 00:05:55.680 --> 00:06:00.399 where whatever work is performance. So from that ied up 116 00:06:01.079 --> 00:06:05.040 getting more into depth tools kind of became a thing 117 00:06:05.079 --> 00:06:09.959 for me. Driving performance initiatives, driving performance as a subject 118 00:06:10.000 --> 00:06:12.839 also all kind of always walked hand in hand with 119 00:06:12.879 --> 00:06:14.800 the tools in a way, at least for me. So 120 00:06:15.120 --> 00:06:17.360 it also walked hand in hand with product, which you know, 121 00:06:17.399 --> 00:06:19.879 in the end brings me very close to being like 122 00:06:19.920 --> 00:06:23.879 a product engineer. So it kind of helps self dog 123 00:06:23.920 --> 00:06:29.199 food within the profession, but it brought me very close 124 00:06:29.240 --> 00:06:32.360 to death tools over time, so I ended up building 125 00:06:32.399 --> 00:06:35.120 integrations with highthouses and very early in the days where 126 00:06:35.160 --> 00:06:37.360 we didn't even have like proper integrations with like house 127 00:06:37.519 --> 00:06:39.879 and work with these kind of things to facilitate and 128 00:06:39.959 --> 00:06:44.279 developers usage of death tooling and performance tooling, and over 129 00:06:44.360 --> 00:06:48.360 time it became kind of the project that I'm currently 130 00:06:48.360 --> 00:06:51.879 building now, which is a fork of depth tools in 131 00:06:51.920 --> 00:06:55.279 a way to bring kind of a different vision of 132 00:06:55.360 --> 00:06:58.399 how I think, not how I think, but like what 133 00:06:59.000 --> 00:07:02.600 could there when it comes to death tools that I 134 00:07:02.639 --> 00:07:05.199 was built for the app let's say, quote unquote the 135 00:07:05.240 --> 00:07:07.800 average developer because one of the biggest problems that I 136 00:07:07.839 --> 00:07:10.399 always faced, and they ended up being the reason why 137 00:07:10.399 --> 00:07:13.480 I ended up working death tools and ended up building 138 00:07:13.480 --> 00:07:16.240 this tool which the two that I say and to 139 00:07:16.319 --> 00:07:18.240 put like, the tool that I'm talking about is called 140 00:07:18.240 --> 00:07:22.040 per Flab and the perfect agent, which is Paul per Flab, 141 00:07:22.240 --> 00:07:24.360 And the reason why I ended up building is just 142 00:07:24.759 --> 00:07:27.519 one of the things that ended up happening. Even like 143 00:07:27.839 --> 00:07:30.720 I worked at Spotify for for almost four years, I 144 00:07:30.759 --> 00:07:33.920 worked to Klina for like almost three years, and a 145 00:07:34.040 --> 00:07:37.120 very common thing was that developers either did not have 146 00:07:37.160 --> 00:07:39.920 as much interest to open the tools and explore the 147 00:07:39.959 --> 00:07:43.639 flame graph and explore you know, those problems the data 148 00:07:43.759 --> 00:07:46.920 behind it, or they were kind of intimidated by it, 149 00:07:47.199 --> 00:07:50.279 even at places such as Spotify and Klina, because it 150 00:07:50.439 --> 00:07:52.920 is a lot of information all at once, and it 151 00:07:53.000 --> 00:07:56.399 is it can become a very noisy, you know tool 152 00:07:56.639 --> 00:07:59.480 if you don't if you're not an expert. So for me, 153 00:08:00.120 --> 00:08:02.319 and then ended up being a way to experiment and 154 00:08:02.399 --> 00:08:06.680 explore how to build something that is approachable by anyone. 155 00:08:07.600 --> 00:08:10.439 So you talking about performance the front end? Sorry, Dan, 156 00:08:11.120 --> 00:08:13.079 it sounds like all yours is on the front end. 157 00:08:13.079 --> 00:08:14.839 You ever do any back end performance stuff or it 158 00:08:14.920 --> 00:08:16.759 was all your performance work pretty much been on the 159 00:08:16.759 --> 00:08:18.560 front end in the browser. 160 00:08:18.680 --> 00:08:20.800 It's being mostly in the browser. 161 00:08:20.480 --> 00:08:24.480 Yeah, because I mean, and so I can remember doing 162 00:08:24.480 --> 00:08:27.759 PHP profiling with like xd bug Kino profiling, So there's 163 00:08:27.759 --> 00:08:30.399 certainly performance on the back end. I think a lot 164 00:08:30.480 --> 00:08:34.159 of people take performance on the back end probably for granted, 165 00:08:34.759 --> 00:08:38.559 you know, because the general rule is if you can 166 00:08:38.759 --> 00:08:40.559 you know, when I'm dealing with a false stack app, 167 00:08:40.600 --> 00:08:43.480 you know, I prefer PHP view with a nurse JS 168 00:08:43.600 --> 00:08:46.559 for instant. That's one of my favorite stacks, and you 169 00:08:46.559 --> 00:08:49.679 can always say if anytime you can offload stuff from 170 00:08:49.720 --> 00:08:51.320 the front end to the back end and get your 171 00:08:51.360 --> 00:08:52.639 data so that when you get to the front end, 172 00:08:52.679 --> 00:08:54.759 you're not doing a bunch of calculations to do that, 173 00:08:54.840 --> 00:08:56.759 because the assumption there is that you're going to have 174 00:08:56.799 --> 00:08:59.679 beef your resources on the back end in terms of 175 00:08:59.679 --> 00:09:02.720 yours and stuff, and so there's probably not as much 176 00:09:03.200 --> 00:09:05.639 performance profiling, although I have known people who have been 177 00:09:05.720 --> 00:09:08.639 really big on performance profiling on the back end, but 178 00:09:08.679 --> 00:09:11.679 I think it's more it's just sort of assumed, Okay, 179 00:09:11.679 --> 00:09:13.360 you're back and can handle us better because you've got 180 00:09:13.360 --> 00:09:15.519 to be for your resources back there, and so the 181 00:09:15.559 --> 00:09:17.799 front ends we're really where we need to focus on 182 00:09:17.879 --> 00:09:18.799 performance stuff. 183 00:09:19.080 --> 00:09:21.360 First of all, I'd like to obviously mention that we've 184 00:09:21.360 --> 00:09:23.360 had quite a number of people on the show in 185 00:09:23.679 --> 00:09:26.879 recent months talking about this topic, So if people are 186 00:09:26.919 --> 00:09:29.480 really interested, there's definitely a lot of shows here to 187 00:09:29.600 --> 00:09:34.159 check out. We've had people from the Google from Google 188 00:09:34.200 --> 00:09:39.799 talking specifically about building the tools we had. I think 189 00:09:39.840 --> 00:09:43.120 I'm not mixing his name up talking about react profiling 190 00:09:43.159 --> 00:09:46.360 the tools that he built for that, So we've had 191 00:09:46.360 --> 00:09:49.200 Harry Roberts, so we've had a lot of people talking 192 00:09:49.200 --> 00:09:52.360 about these subjects. So there's definitely a lot if people 193 00:09:52.440 --> 00:09:55.360 are interested, there's definitely a lot of content here on 194 00:09:55.399 --> 00:09:59.559 the podcast about it. But going specifically to your point, Steve, 195 00:10:00.159 --> 00:10:03.679 it's you know, it's it's tricky because very often it 196 00:10:03.840 --> 00:10:06.960 is about the back end because it might be just 197 00:10:07.320 --> 00:10:11.679 simply an SQL query that's not properly optimized or doesn't 198 00:10:11.720 --> 00:10:16.320 have the properity indexes defined and runs way too slowly 199 00:10:16.440 --> 00:10:19.519 and something like that. But on the other hand, it 200 00:10:19.600 --> 00:10:23.159 could your back end could be really, really well optimized, 201 00:10:23.360 --> 00:10:27.039 but it's worthless because, as I give an example before, 202 00:10:27.200 --> 00:10:30.720 you're downloading a huge image and that's just eating up 203 00:10:30.720 --> 00:10:33.600 all your bandwidth, regardless of anything else that you're doing. 204 00:10:34.320 --> 00:10:37.120 So you really kind of need to take a holistic 205 00:10:37.279 --> 00:10:42.120 view of performance and try to pinpoint the you know, 206 00:10:42.240 --> 00:10:46.279 the root causes and identify bottlenecks. And that's usually what 207 00:10:46.360 --> 00:10:52.399 dev tooling is for, is for identifying those and understanding 208 00:10:52.480 --> 00:10:56.000 what to focus on and doing the proper attribution of 209 00:10:56.200 --> 00:11:00.360 locating the areas that are most problematic exactly. 210 00:11:00.440 --> 00:11:02.639 And it's really like that's one of the main reasons 211 00:11:02.679 --> 00:11:04.759 why performance is such a difficult subject. Right, I like 212 00:11:04.799 --> 00:11:07.360 to become let's say, an expert, even like someone that 213 00:11:07.639 --> 00:11:11.600 is confident to solve performance problems. Is a very steep 214 00:11:11.720 --> 00:11:15.360 vertical The tooling can be somewhat intimidating if you never 215 00:11:15.879 --> 00:11:19.440 you know, delve tape into it or dedicated the hours 216 00:11:19.440 --> 00:11:23.720 for it and force for experienced developers or specialists, what 217 00:11:23.960 --> 00:11:26.799 is information can be noise for let's say the average 218 00:11:26.799 --> 00:11:30.960 developer that doesn't go around on debt tools as much. 219 00:11:31.399 --> 00:11:35.399 So with that premise, I was interested on experimenting around 220 00:11:35.639 --> 00:11:37.759 and seeing, you know, what I could come up with, 221 00:11:38.519 --> 00:11:42.519 So I ended up working Chrome dept Tools. The advantage 222 00:11:42.519 --> 00:11:45.480 of Crome dept Tools. First of all, the source code 223 00:11:45.559 --> 00:11:48.759 is beautifully documented, so self phone boarding on it very easily, 224 00:11:49.559 --> 00:11:53.360 was very easy on It is Web components with typescripts, 225 00:11:53.480 --> 00:11:56.639 so it's actually web technology, so it's really approachable for 226 00:11:56.679 --> 00:11:57.960 the average developer out there. 227 00:11:58.519 --> 00:12:01.480 Yeah, who would have thought that Web thev tooling is 228 00:12:01.519 --> 00:12:03.720 built on web technologies like Inception. 229 00:12:04.519 --> 00:12:06.679 Yeah, I mean because a lot of people think it's 230 00:12:07.000 --> 00:12:09.639 simpless plus right, Like because the browser, the Chrome, the 231 00:12:09.639 --> 00:12:12.440 main chrome is simplus plus the main interface, so a 232 00:12:12.440 --> 00:12:15.000 lot of people actually end up thinking it is simplus plus, 233 00:12:15.039 --> 00:12:18.440 which is not the case. It is built on top 234 00:12:18.440 --> 00:12:21.960 of web technologies, but it communicates through the browser view 235 00:12:22.000 --> 00:12:25.840 the debugging protocol, and it communicates also via the different 236 00:12:25.879 --> 00:12:29.559 protocols and within the native layer. I ended up working it, 237 00:12:29.759 --> 00:12:33.879 and the first try around was building per flab as 238 00:12:33.919 --> 00:12:37.279 in the main let's say the main app, and per 239 00:12:37.279 --> 00:12:41.440 flab was a fork of the Performance Panel, so extracting 240 00:12:41.480 --> 00:12:43.919 it as a sound alone web component. It is already 241 00:12:43.919 --> 00:12:46.440 built on web components, so extracting it was was not 242 00:12:46.519 --> 00:12:49.480 as hard. And what ended up happening that I noticed 243 00:12:49.519 --> 00:12:53.960 is that because I still used the performance a panel 244 00:12:54.200 --> 00:12:58.279 as the main interface to drive interactions around stead of 245 00:12:58.399 --> 00:13:01.600 being something very close to like dashboard. And one of 246 00:13:01.600 --> 00:13:04.360 the things that I that I constantly had a gripe 247 00:13:04.360 --> 00:13:07.440 with is that dashboards can be also very daunting and 248 00:13:07.440 --> 00:13:10.320 its sub utilized. Like a lot of dashboard systems and 249 00:13:11.080 --> 00:13:15.200 SaaS companies have really good product, but it's heavily understand 250 00:13:15.279 --> 00:13:18.360 underutilized because people don't understand the data, they didn't understand 251 00:13:18.399 --> 00:13:20.240 what they want to extract out of the data, end 252 00:13:20.320 --> 00:13:23.120 up sub utilizing the systems and so ended up being 253 00:13:23.200 --> 00:13:27.519 not as you know, initiate like friendly for earlier stage 254 00:13:27.559 --> 00:13:31.080 developers or developers that don't have performance as their main 255 00:13:31.519 --> 00:13:33.559 for tail, let's say, their main subjects. 256 00:13:33.840 --> 00:13:38.639 It's interesting that this is something that Google themselves have realized, 257 00:13:38.759 --> 00:13:43.399 like that the performance tab is really daunting. It's a 258 00:13:43.480 --> 00:13:48.440 very very busy interface with a ton of information, and 259 00:13:48.600 --> 00:13:53.759 they actually created an alternative tab I think it was 260 00:13:53.879 --> 00:13:58.279 called Performance Insights or something like that, which was, as 261 00:13:58.559 --> 00:14:01.200 we've been told on the show, never intended to be 262 00:14:01.399 --> 00:14:04.679 like a long term solution. Rather, it was this kind 263 00:14:04.720 --> 00:14:08.919 of a playground where they were testing out various alternative 264 00:14:09.000 --> 00:14:13.840 ideas that they thought that they would eventually bring back 265 00:14:13.919 --> 00:14:17.360 into the main performance steps. So kind of playground to 266 00:14:17.440 --> 00:14:21.600 try out various optimizations and way of making the interface 267 00:14:22.159 --> 00:14:26.639 clearer and easier to understand, especially to junior developers. 268 00:14:26.799 --> 00:14:30.159 And the Chrome team has been on an absolute role 269 00:14:30.240 --> 00:14:33.320 when it comes to improving the experience around that tools 270 00:14:33.360 --> 00:14:38.080 in general. So my next adventure with building something with 271 00:14:38.679 --> 00:14:43.440 that tools was I think about like three years ago, no, sorry, 272 00:14:43.519 --> 00:14:46.080 about a year and a half ago. So when AI 273 00:14:46.080 --> 00:14:49.519 in general became more broadly disc like part of the 274 00:14:49.559 --> 00:14:54.559 common discourse, we started having better developer frameworks for building 275 00:14:54.600 --> 00:14:56.519 with AI and stuff like that. So I was like, 276 00:14:56.960 --> 00:14:58.919 and everyone was building their own chatbots in a way, 277 00:14:59.039 --> 00:15:01.399 so I was like, you know, I'm gonna I'm gonna 278 00:15:01.399 --> 00:15:05.039 see if I can build something that is approachable for anyone. 279 00:15:05.240 --> 00:15:08.759 And so like I remember being I think it was 280 00:15:09.440 --> 00:15:13.399 last year's perth Now talking with the different people from 281 00:15:13.480 --> 00:15:15.200 the death Tools. 282 00:15:16.240 --> 00:15:19.000 And I also don't know, by the way, Perfonal Performance 283 00:15:19.080 --> 00:15:23.320 Now is, yes, probably the leading performance related conference takes 284 00:15:23.320 --> 00:15:26.240 place in Amsterdam, so that's actually fairly close to you. 285 00:15:26.919 --> 00:15:29.240 Yeah. Yeah, and I'm gonna be there this year as well. 286 00:15:29.519 --> 00:15:32.679 I'm going to be actually talking this year. Oh cool. Yes, 287 00:15:32.840 --> 00:15:35.039 it's been on a very similar subject. So this is 288 00:15:35.080 --> 00:15:37.919 kind of like a teaser, I say, long long form 289 00:15:38.080 --> 00:15:41.399 teaser of the talk. But so within you know, last 290 00:15:41.480 --> 00:15:44.639 year's a perf Now I brought up with different members 291 00:15:44.639 --> 00:15:47.600 of the death Tools teams like uh, kind of like 292 00:15:48.759 --> 00:15:52.159 let's say a thought exercise of what could it be 293 00:15:52.960 --> 00:15:56.200 that the smallest possible subset of a depth too looks 294 00:15:56.279 --> 00:16:00.000 like and you know, helps people engage with it without 295 00:16:00.159 --> 00:16:02.840 being daunting. So this this was kind of like the 296 00:16:02.840 --> 00:16:05.720 thig exercise. I was trying to to to have within 297 00:16:05.759 --> 00:16:07.759 those conversations and a lot of things, and I was 298 00:16:07.799 --> 00:16:12.360 demoing perth Lab in within the within Perth now as 299 00:16:12.360 --> 00:16:15.279 well get like gathering some some talks and discussions around 300 00:16:15.320 --> 00:16:18.879 the tools building. So early this year I started, I 301 00:16:18.960 --> 00:16:23.799 decided to build Perth Agent. So with perf Agent, startled 302 00:16:23.840 --> 00:16:27.360 with the same kind of spirit of birth Lab, working 303 00:16:27.919 --> 00:16:32.480 part of Chrome def tools. So within going too much 304 00:16:32.519 --> 00:16:35.679 into details, so we have some some partitive depth tools. 305 00:16:35.759 --> 00:16:38.960 There are the drivers of how dev tools reads and 306 00:16:39.879 --> 00:16:44.360 trace information. So that trace Engine is something that I 307 00:16:44.440 --> 00:16:47.840 then extracted. So instead of going for the main performance panel, 308 00:16:47.879 --> 00:16:50.759 I started to take trace Engine to help me extract 309 00:16:50.759 --> 00:16:54.919 information out of traces and with that create my own 310 00:16:55.039 --> 00:16:57.919 agent that's that can understand traces and try to help 311 00:16:58.080 --> 00:17:01.039 people to solve performance problems. So in a way I 312 00:17:01.080 --> 00:17:02.919 ended up building a chat what in a way. But 313 00:17:03.600 --> 00:17:05.920 the some of the things I was trying to play 314 00:17:05.920 --> 00:17:09.519 with is of course with the advent of generative UI, 315 00:17:09.920 --> 00:17:13.519 build that thought process of what is the smallest possible 316 00:17:13.559 --> 00:17:15.400 self self of a debt tool that I can build 317 00:17:15.599 --> 00:17:20.400 that is progressive and which means it doesn't present all 318 00:17:20.400 --> 00:17:23.000 the information at once, so it tries to be more 319 00:17:23.039 --> 00:17:27.319 friendly also like a knowledge assistant and helps with solving 320 00:17:27.359 --> 00:17:31.319 performance problems, building on top of AI agents that can understand, 321 00:17:31.640 --> 00:17:34.920 you know, trace files and can understand calls, tax and 322 00:17:34.920 --> 00:17:38.480 all this kind of stuff and help you solve problems. 323 00:17:39.000 --> 00:17:42.920 So just to understand, you're building this what as an 324 00:17:42.960 --> 00:17:47.880 open source project, as a service, as a product that 325 00:17:47.960 --> 00:17:50.960 you intend to sell as all of the above, what 326 00:17:51.200 --> 00:17:52.359 is it? 327 00:17:51.359 --> 00:17:56.400 It's a very good question. I am. I'm building it. 328 00:17:55.960 --> 00:17:59.200 It's going to be open source, like within the next 329 00:17:59.279 --> 00:18:02.000 couple of weeks, just cleaning up parts of the code 330 00:18:02.119 --> 00:18:03.519 and making sure that it is in a good state 331 00:18:03.599 --> 00:18:07.279 to be open sourced and collaborated with more people because 332 00:18:07.319 --> 00:18:09.799 it's been just me so far, long givings and whatnot. 333 00:18:09.920 --> 00:18:13.799 But it's also up of a flab so people can 334 00:18:14.200 --> 00:18:16.240 not that they can join the wait list, and I'm 335 00:18:16.400 --> 00:18:20.279 slowly getting people on boarded into the service, mostly because 336 00:18:20.440 --> 00:18:23.079 it's just me. So inference costs is a thing as well, 337 00:18:23.200 --> 00:18:26.119 one of the biggest being with the eyes inference costs. 338 00:18:25.359 --> 00:18:29.799 So I'm going to come up with probably some form 339 00:18:29.839 --> 00:18:33.559 of pricing model or hopefully sponsorship to keep it free 340 00:18:33.960 --> 00:18:37.799 or whatever. But I don't have any. I didn't have 341 00:18:37.839 --> 00:18:41.920 any necessarily like any big plans for it because it's 342 00:18:41.920 --> 00:18:44.759 built on top of the open source and like most 343 00:18:44.880 --> 00:18:50.200 of the tools I use nowadays, it's kind of let's 344 00:18:50.200 --> 00:18:53.799 say common ground. It used to be more the secret 345 00:18:53.839 --> 00:18:57.559 sauce as people say, where the system prompts, how you 346 00:18:57.640 --> 00:19:01.240 organize the workflow, and how you organized the tools used 347 00:19:01.240 --> 00:19:03.960 to be a big power of differentiates one a itol 348 00:19:04.000 --> 00:19:07.599 from another. But as everyone pretty much started doing this, 349 00:19:07.920 --> 00:19:10.279 it became less important so much to a lot a 350 00:19:10.279 --> 00:19:14.640 lot of different companies open source their system prompts and 351 00:19:14.680 --> 00:19:17.319 how they they're building workflows and things like that. Even 352 00:19:17.559 --> 00:19:20.400 Yes code now with Copalative open sources the system props. 353 00:19:20.400 --> 00:19:23.119 That is so so I'll ask my question in a 354 00:19:23.160 --> 00:19:27.319 slightly different way. Is this your day job? No, it's not. No, 355 00:19:27.400 --> 00:19:29.960 it's not my day job. It's a good question. It's 356 00:19:29.960 --> 00:19:33.720 been a passion project. It's being evenings and weekends building 357 00:19:33.759 --> 00:19:36.559 this stuff. Because now we live in a very interesting 358 00:19:36.640 --> 00:19:43.480 point in time where there is this inflection point kind 359 00:19:43.480 --> 00:19:46.799 of coming and I feel like the like as a developer, 360 00:19:46.799 --> 00:19:49.920 as an engineer, I'm naturally curious, and I feel like 361 00:19:50.079 --> 00:19:52.680 it's one of the things that a good engineer is 362 00:19:52.680 --> 00:19:55.960 is that natural curiosity to try stuff and see where 363 00:19:55.960 --> 00:19:58.559 they fit within your workflow. But I did not want 364 00:19:58.640 --> 00:20:01.119 to just be a consumer. I also wanted to build 365 00:20:01.160 --> 00:20:03.480 something with it, and so I ended up studying some 366 00:20:03.839 --> 00:20:07.759 you know, even deeper ends of models and model platform 367 00:20:07.880 --> 00:20:12.880 architectures and how to train models, the whole stuff. So 368 00:20:12.960 --> 00:20:15.640 much so that actually as a side thing, I ended 369 00:20:15.720 --> 00:20:20.319 up building the workflow to kind of simulate the mystery 370 00:20:20.359 --> 00:20:24.400 of experts architecture, where you have like a router that 371 00:20:24.680 --> 00:20:28.319 delegates to different workflows and different especialists. Because the whole 372 00:20:28.519 --> 00:20:32.119 if you think about performance, as we just opened up 373 00:20:32.200 --> 00:20:35.839 the show, it has different subjects, right, and that's one 374 00:20:35.839 --> 00:20:37.920 of the biggest challenges of building a system, an AI 375 00:20:38.039 --> 00:20:41.000 system with a complex subject such as performance, because it's 376 00:20:41.079 --> 00:20:44.279 very deep and also has different branches that goes all 377 00:20:44.319 --> 00:20:47.440 of them go through Deep and Google kind of like 378 00:20:47.519 --> 00:20:50.839 if you go digging around the Depth Tools source code, 379 00:20:50.880 --> 00:20:52.759 you will see that they're using kind of the same 380 00:20:52.759 --> 00:20:57.319 approach where they have AI agents that represent different parts 381 00:20:57.400 --> 00:20:59.559 of the Depth tools. You have one for the network 382 00:20:59.680 --> 00:21:02.519 one or call frames, one for CSS, one for elements. 383 00:21:02.839 --> 00:21:05.000 So it's a very similar way but then within the 384 00:21:05.039 --> 00:21:08.200 whole thing that I built is has like a router 385 00:21:08.480 --> 00:21:11.680 that that we understand the request and you know, navigate 386 00:21:12.359 --> 00:21:17.559 workflows and different specialists to to call within you know, 387 00:21:17.640 --> 00:21:21.680 the two chain. But it's like it's a very interesting 388 00:21:21.720 --> 00:21:23.480 inflection point that we're going to have in a few 389 00:21:23.480 --> 00:21:26.519 in the next few years, and experimenting with it, it's 390 00:21:26.880 --> 00:21:29.880 felt like almost like an obligation to me to understand 391 00:21:31.440 --> 00:21:34.519 where do all of us fit in within the next 392 00:21:34.519 --> 00:21:37.279 few years as developer, where does the web even fitting 393 00:21:37.319 --> 00:21:39.279 Because one of the things that I started thinking a 394 00:21:39.319 --> 00:21:42.240 lot about is and that's ended up being the reason 395 00:21:42.240 --> 00:21:46.200 why and they're building PERF agent is what is a 396 00:21:46.240 --> 00:21:49.519 dev tool in this new era when we can have 397 00:21:49.599 --> 00:21:52.839 agents kind of talking to each other solving problems. So 398 00:21:53.319 --> 00:21:58.119 last week we had last week we had I you 399 00:21:58.240 --> 00:22:01.680 connect and for you connects. One of the things that 400 00:22:01.680 --> 00:22:06.000 I wanted to do for your connect is to see 401 00:22:06.079 --> 00:22:08.480