WEBVTT 1 00:00:05.480 --> 00:00:09.199 Hello everybody, and welcome to a super exciting episode of 2 00:00:09.400 --> 00:00:13.720 JavaScript Jabber. Today on our panel, we have a j O'Neill. 3 00:00:14.439 --> 00:00:17.120 Yo ya yo coming at you live, healthy and well 4 00:00:17.280 --> 00:00:18.960 from the perfect temperature in the shed. 5 00:00:20.399 --> 00:00:25.280 It's been a while and me I'm your host today, 6 00:00:25.480 --> 00:00:28.600 Dan Shapier from Tel Aviv in Israel. And today our 7 00:00:28.640 --> 00:00:37.479 guests are Matteo Colina Hi, Matteo, Hello everyone, James Snell Hi, James, Hello, 8 00:00:38.359 --> 00:00:40.960 and Michael Dawson Hi Michael, Hi. 9 00:00:40.799 --> 00:00:41.359 How are you doing? 10 00:00:42.520 --> 00:00:45.280 And today we brought you all over to talk about 11 00:00:45.320 --> 00:00:51.039 this excellent article post you know that you've written. I 12 00:00:51.079 --> 00:00:53.320 loved it very much, to the extent that as soon 13 00:00:53.359 --> 00:00:55.880 as I saw it, I contacted Matteo and told him 14 00:00:56.039 --> 00:00:58.280 you have to come on our show to talk about this. 15 00:00:59.399 --> 00:01:01.520 All you guys is out there should also read it 16 00:01:01.640 --> 00:01:04.480 regardless of what we talk about it here. And it's 17 00:01:04.519 --> 00:01:08.719 called the nine Note Pillars Nine Principles for doing no 18 00:01:08.879 --> 00:01:14.079 JS Right in enterprise environments. As I said, this is 19 00:01:14.120 --> 00:01:17.319 an awesome article. Who wants to start talking about it? 20 00:01:17.879 --> 00:01:19.359 So just go read it? I mean it is. 21 00:01:19.439 --> 00:01:20.159 Yeah. 22 00:01:20.439 --> 00:01:24.680 Okay, let me start these articles cars from an idea, 23 00:01:25.439 --> 00:01:30.319 from start from experience, Okay, start from at the key 24 00:01:31.439 --> 00:01:36.879 the experience of you know, developers do no JS all 25 00:01:36.920 --> 00:01:39.640 the time. They think they know no JS, and they 26 00:01:39.680 --> 00:01:41.239 don't know no no js. 27 00:01:42.799 --> 00:01:46.120 Okay, that's pretty unfortunate statement. 28 00:01:46.920 --> 00:01:49.560 It's no, it's true, it's true. It's absolutely true. You know, 29 00:01:50.120 --> 00:01:53.280 Mitteil and I, you know, when both of our previous 30 00:01:53.319 --> 00:01:55.920 employment we were working with a lot of consulting work, 31 00:01:55.959 --> 00:02:00.519 going out with customers and seeing the same problem over 32 00:02:00.560 --> 00:02:03.280 and over and over again, and in every single case, 33 00:02:03.319 --> 00:02:06.439 it always came down to folks not really understanding how 34 00:02:06.760 --> 00:02:11.199 node worked internally, like you know, what what how does 35 00:02:11.199 --> 00:02:12.080 the event loop workers? 36 00:02:12.120 --> 00:02:15.319 And I thinks it just occurred to me that I 37 00:02:15.439 --> 00:02:20.719 skipped a very important point while starting this conversation, and 38 00:02:20.800 --> 00:02:23.840 that's like who you guys are and why it is 39 00:02:23.879 --> 00:02:27.759 that you guys actually do know so much about how 40 00:02:27.879 --> 00:02:31.599 node works and how it should be used. So maybe 41 00:02:31.840 --> 00:02:35.479 you should, you guys should do a brief introduction of yourselves. 42 00:02:36.680 --> 00:02:38.599 Yeah, yeah, we can do that. I'm going a good 43 00:02:38.599 --> 00:02:43.719 person and let the guys go next year. So James, 44 00:02:43.800 --> 00:02:45.879 now I've been you know, I'm currently with cloud Flaer 45 00:02:45.879 --> 00:02:50.400 work on the workers run time. But you know, a 46 00:02:50.400 --> 00:02:53.360 lot longer than that. I've been involved with NOTE, coming 47 00:02:53.439 --> 00:02:58.039 up almost on ten years involved with Node, and at 48 00:02:58.039 --> 00:03:00.400 the end of this year will be exactly ten years 49 00:03:02.159 --> 00:03:04.840 prior to my current player. You know, you know, Matteo 50 00:03:04.879 --> 00:03:08.319 and I were doing all kinds of consulting work around node, 51 00:03:09.439 --> 00:03:13.919 use of Node, how to do things correctly, help people 52 00:03:13.919 --> 00:03:18.800 with performance, performance problems they're having, that kind of thing. 53 00:03:18.960 --> 00:03:22.560 But also just I've been contributing a lot to NOTE. 54 00:03:22.639 --> 00:03:24.439 So a lot of the things like the r L 55 00:03:24.680 --> 00:03:26.719 you know, the original euro parts are not the original, 56 00:03:26.840 --> 00:03:30.479 but the w G H and HB two and a 57 00:03:30.479 --> 00:03:32.639 bunch of other things that have been involved with with 58 00:03:32.639 --> 00:03:33.680 with adding. So that's me. 59 00:03:33.759 --> 00:03:36.520 That's my fact part in your roles. That must be 60 00:03:36.599 --> 00:03:37.159 so easy. 61 00:03:38.199 --> 00:03:43.120 Yeah, no, you can, I recommend for for a future episode. 62 00:03:43.319 --> 00:03:46.639 Get yagis on here. He did the the eight of 63 00:03:46.879 --> 00:03:49.199 RL implementation that NOTE now uses and he can tell 64 00:03:49.199 --> 00:03:51.159 you why it's not easy at all. 65 00:03:51.560 --> 00:03:54.719 So yeah, I know I was just being faspicious. 66 00:03:55.599 --> 00:03:56.840 Yeah, I'm Michael Dawson. 67 00:03:56.960 --> 00:03:59.520 I'm the NODS lead for rad Hot and IBM, and 68 00:04:00.039 --> 00:04:03.000 I got you know, if I actually got involved in 69 00:04:03.039 --> 00:04:06.240 the project around the same time that James Hayes and 70 00:04:06.319 --> 00:04:09.199 so been working for a very long time in the project, 71 00:04:09.240 --> 00:04:12.360 a member of the technical Steering Committee, working a whole 72 00:04:12.400 --> 00:04:16.800 bunch of the different working groups, particular like note at 73 00:04:16.879 --> 00:04:18.920 on API is one of the ones that I'm pretty 74 00:04:18.920 --> 00:04:21.959 active in in the build working group. And I think 75 00:04:22.000 --> 00:04:24.720 back to your earlier question, is like, I think that 76 00:04:24.800 --> 00:04:28.800 the challenges is that you can very easily get started 77 00:04:28.839 --> 00:04:31.079 with GS, but actually getting it right is a little 78 00:04:31.079 --> 00:04:31.920 bit more difficult. 79 00:04:31.920 --> 00:04:34.079 And that's why we we you know, we see. 80 00:04:33.920 --> 00:04:37.120 Things like some specific guidance can really help people going forward. 81 00:04:37.399 --> 00:04:38.040 Over to Matteo. 82 00:04:39.000 --> 00:04:41.920 So hi, hi folks, I am a little bit under 83 00:04:41.920 --> 00:04:43.680 the weather today, so I'm sorry. I didn't want to 84 00:04:44.519 --> 00:04:49.240 defer the recording. So so sorry if I'm less, I 85 00:04:49.279 --> 00:04:57.839 don't know, excited as you. It's look, well, well I 86 00:04:57.879 --> 00:04:59.839 have I have a lot at this point, have been 87 00:04:59.879 --> 00:05:02.120 doing been doing the JS for a long time. I 88 00:05:02.160 --> 00:05:08.680 have accumulated a few hundreds MPM deployed a few hundreds 89 00:05:09.519 --> 00:05:15.079 modules on MPM, which more or less total a very 90 00:05:15.199 --> 00:05:18.519 nice one percent, close to one percent of the total 91 00:05:18.600 --> 00:05:23.399 number of down of downloads of MPM itself. Wow, it's 92 00:05:23.439 --> 00:05:27.160 it's a little bit unbelievable to be honest, the numbers 93 00:05:27.160 --> 00:05:30.360 are you know, it has way too many zeros in them. 94 00:05:30.600 --> 00:05:33.439 Okay, you've been busy. 95 00:05:33.759 --> 00:05:37.000 Well yeah, everybody seems to love the code that I 96 00:05:37.120 --> 00:05:43.240 pushed that they push out for free. So anyway, a 97 00:05:43.319 --> 00:05:48.720 few years back, I started this company called Platformatic two 98 00:05:50.920 --> 00:05:53.399 you know, to push not to the next level, and 99 00:05:53.439 --> 00:05:57.079 that's where what we are trying to do, and and 100 00:05:57.160 --> 00:06:00.079 we have been trying to fund some of those initiatives 101 00:06:00.399 --> 00:06:02.839 and things and promote no js. 102 00:06:03.240 --> 00:06:04.319 So here we are. 103 00:06:06.680 --> 00:06:11.160 Cool. Now, you guys all work at different companies, so 104 00:06:11.319 --> 00:06:14.079 you're obviously all three of you very much involved in node, 105 00:06:15.000 --> 00:06:17.959 but your day job is at different places. How did 106 00:06:17.959 --> 00:06:20.040 it happen that all of the three of you came 107 00:06:20.079 --> 00:06:22.079 together to write this article? 108 00:06:22.560 --> 00:06:23.439 Oh, I can take this. 109 00:06:23.720 --> 00:06:26.480 So basically it's actually one person that is missing in 110 00:06:26.480 --> 00:06:28.959 this call, which is Natalia that was also part of 111 00:06:29.000 --> 00:06:29.480 the review. 112 00:06:29.959 --> 00:06:35.319 Okay. And Natalia is also the lead owner and for 113 00:06:35.560 --> 00:06:39.720 JavaScript the X and have tools for Azure and the 114 00:06:39.800 --> 00:06:42.920 four of us like this started from my idea, from 115 00:06:43.560 --> 00:06:46.800 an idea that I had a few months back and says, look, 116 00:06:46.879 --> 00:06:50.120 how come we can how can we promote and solidify 117 00:06:50.360 --> 00:06:51.079 that knowledge? 118 00:06:51.199 --> 00:06:59.680 Okay? And how can we stop start pushing back against the. 119 00:07:01.120 --> 00:07:03.920 All the bad tutorials, all the bad all the bad 120 00:07:03.959 --> 00:07:07.959 practices that are out there and plugging every single not 121 00:07:08.079 --> 00:07:11.920 JS code base that I have that I've seen, Okay. 122 00:07:11.600 --> 00:07:13.639 Because that's that's frankly what it is. 123 00:07:14.199 --> 00:07:17.519 So at that time I started looking, and I said 124 00:07:17.560 --> 00:07:21.279 that I picked a few friends and decided, look, who 125 00:07:21.279 --> 00:07:24.399 can who can I ask? I want a presentation for 126 00:07:24.480 --> 00:07:28.000 a bunch of different companies and so on. So and 127 00:07:28.279 --> 00:07:31.439 let's try to put our our minds together and write 128 00:07:31.439 --> 00:07:38.959 something up that can be uh that you know, we 129 00:07:39.040 --> 00:07:42.879 can be happy with and can help developers you know 130 00:07:43.120 --> 00:07:46.519 you're doing no J as well, and stop those you know, 131 00:07:46.680 --> 00:07:52.879 Spaghetti's code mess that they do most of the time. 132 00:07:53.279 --> 00:07:56.839 So yeah, and one important point of me is like, 133 00:07:56.879 --> 00:07:59.079 none of none of the information in this pod post 134 00:07:59.160 --> 00:08:02.399 is new. It's stuff that we've talked about and talks 135 00:08:02.399 --> 00:08:05.680 over the years for conferences and workshops, and you know, 136 00:08:05.720 --> 00:08:09.639 each of us in various ways have have talked about 137 00:08:09.680 --> 00:08:13.439 these things before. Unfortunately, a lot of that gets kind 138 00:08:13.439 --> 00:08:15.279 of washed out in the noise. It's like, you know, 139 00:08:15.319 --> 00:08:19.000 there's so many of these tutorials that just kind of 140 00:08:19.000 --> 00:08:22.519 get things wrong. And it ends up washing out the 141 00:08:23.160 --> 00:08:26.639 good information. Uh, just kind of in that noise. And 142 00:08:26.680 --> 00:08:29.600 so it's like many times we can repeat this stuff, 143 00:08:30.000 --> 00:08:30.680 get it out there. 144 00:08:31.279 --> 00:08:31.480 You know. 145 00:08:31.839 --> 00:08:34.000 I'd like to see us like repeat this again like 146 00:08:34.159 --> 00:08:36.480 a year from now, just kind of keep reiterating on it, 147 00:08:36.600 --> 00:08:37.200 keep going. 148 00:08:37.519 --> 00:08:43.759 Uh, gets on again and again in the future. Individually altogether, 149 00:08:44.360 --> 00:08:48.919 just say the word Obviously, we will enumerate through the 150 00:08:48.960 --> 00:08:52.159 pillars and look talk about the positive stuff and the 151 00:08:52.200 --> 00:08:54.600 things that that need that should be done, and it 152 00:08:54.720 --> 00:08:57.440 can be done and need to be done. But to 153 00:08:57.519 --> 00:08:59.799 make it spicy, I do actually want to start with 154 00:08:59.840 --> 00:09:02.600 some of the negatives. If you don't mind. You guys 155 00:09:02.639 --> 00:09:06.960 said that you encounter so many bad practices and so 156 00:09:07.279 --> 00:09:11.919 much bad advice and bad code, and without naming names, 157 00:09:12.360 --> 00:09:14.120 can you give some examples. 158 00:09:17.039 --> 00:09:20.000 Oh yeah, we can do whole whole examples. I'm gonna 159 00:09:20.480 --> 00:09:24.519 a couple years ago the top guys, I did a 160 00:09:24.559 --> 00:09:27.080 talk called broken Promises. There there's you can you can 161 00:09:27.120 --> 00:09:29.519 find it on YouTube, and I credit with the work 162 00:09:29.639 --> 00:09:33.399 some workshops just that you know, kind of breaks down 163 00:09:33.840 --> 00:09:37.480 some of the really bad ways people just get things wrong, 164 00:09:37.519 --> 00:09:40.759 particularly around promises, because they just don't understand how they work. 165 00:09:41.960 --> 00:09:45.639 I had one former consulting customer I walked in was. 166 00:09:45.600 --> 00:09:49.600 Doing a workshop their their their lead engineer on the 167 00:09:49.679 --> 00:09:54.799 team started arguing with me because he believed that creating 168 00:09:54.879 --> 00:09:57.519 new promise was just like creating new thread and Java. 169 00:09:58.360 --> 00:10:02.840 So no, it's completely different model. And this is their 170 00:10:02.919 --> 00:10:05.879 lead engineer on on on the team. Because it just 171 00:10:06.159 --> 00:10:10.080 did not understand how how this works, and it just 172 00:10:10.120 --> 00:10:12.600 we just kept encountering that over and over and over again, 173 00:10:12.639 --> 00:10:13.399 that kind of stuff. 174 00:10:14.879 --> 00:10:18.519 I just posted the link, by the way, Uh, we'll 175 00:10:18.559 --> 00:10:20.679 also put it in the show notes to that talk. 176 00:10:21.399 --> 00:10:24.840 So yeah, that's that's pretty amazing. Like I can understand 177 00:10:24.840 --> 00:10:28.080 why somebody might confuse a worker with a thread, but 178 00:10:28.240 --> 00:10:31.320 confusing a promise with a thread that's pretty extreme. 179 00:10:32.200 --> 00:10:35.519 But look, we can even go to more of way 180 00:10:35.600 --> 00:10:40.519 more basic stuff, okay, like like the best. Let's let's 181 00:10:40.519 --> 00:10:43.399 talk a little bit about updating no JS updated not 182 00:10:43.639 --> 00:10:46.879 do not use uh deprecated code. 183 00:10:48.360 --> 00:10:49.679 It's unbelievable. 184 00:10:50.120 --> 00:10:55.879 Okay, the companies are not updating no JS like this 185 00:10:56.039 --> 00:10:56.720 seems you know. 186 00:10:56.799 --> 00:10:57.360 It's it's. 187 00:11:00.000 --> 00:11:03.720 Should deploy something though it's working. Just let it be right. 188 00:11:04.200 --> 00:11:07.200 I mean, I know a lot of companies, are you know, 189 00:11:07.360 --> 00:11:09.960 in some sort of hype cycle where they're just deploying 190 00:11:09.960 --> 00:11:13.120 the latest framework every other day. But I think a 191 00:11:13.159 --> 00:11:17.799 lot of profitable companies are creating a product and once 192 00:11:17.840 --> 00:11:21.039 that product is good, they're they're not gonna rock the 193 00:11:21.080 --> 00:11:23.879 boat on it every five minutes. They're gonna let it cook. 194 00:11:24.720 --> 00:11:28.480 Also, you know that old joke about that the developer 195 00:11:28.559 --> 00:11:33.799 and his son walking down the road and the boy says, Dad, 196 00:11:33.879 --> 00:11:37.200 why does the sun rise in the east, And the 197 00:11:37.240 --> 00:11:42.279 father says, it works, don't touch it. 198 00:11:43.320 --> 00:11:47.840 Those are good points. Those are good points. But you know, 199 00:11:48.039 --> 00:11:50.519 no one wants to use software that is full of 200 00:11:50.559 --> 00:11:52.279 security and vulnerabilities. 201 00:11:52.879 --> 00:11:54.480 Well, maybe they should stop putting them in. 202 00:11:54.440 --> 00:11:59.360 The oh, maybe they should stop putting their product on 203 00:11:59.399 --> 00:12:04.600 the Internet. Then that's a pretty eastern way to be pulled. 204 00:12:04.639 --> 00:12:09.120 The blog it's it's it's secure by default, Okay. 205 00:12:09.279 --> 00:12:12.919 I mean, so the application and an application that has 206 00:12:13.039 --> 00:12:15.399 proper isolation around it. And I say, if all of 207 00:12:15.440 --> 00:12:17.799 the routes coming into that thing are secured and it's 208 00:12:17.840 --> 00:12:20.840 not exposed to the Internet, it's just like a long 209 00:12:20.919 --> 00:12:25.399 running enterprise application that's there to support existing business processes. 210 00:12:25.720 --> 00:12:28.440 If they don't update, they don't update that doesn't matter 211 00:12:28.480 --> 00:12:32.559 because because they have that isolation, and the types of 212 00:12:32.600 --> 00:12:35.879 threats that are coming at that server, you know, are 213 00:12:35.919 --> 00:12:38.080 much more limited. But if something's out on the internet, 214 00:12:38.159 --> 00:12:40.679 if it's exposed to the internet, you know, you don't 215 00:12:40.679 --> 00:12:44.679 want to have software running that has these security vulnerabilities. 216 00:12:44.679 --> 00:12:49.600 You really should update. And as updating, you know, you 217 00:12:49.639 --> 00:12:51.679 can't just quite throw a new version out there. You 218 00:12:51.679 --> 00:12:53.799 need to see what other changes are going on. Like 219 00:12:54.120 --> 00:12:57.879 we'll deprecate things that we really people really should not 220 00:12:58.000 --> 00:13:01.799 use because it could be a security vulnerability. But we 221 00:13:01.919 --> 00:13:03.639 you know, but removing it or changing the way it 222 00:13:03.639 --> 00:13:05.279 works is too much of a breaking change, and we 223 00:13:05.320 --> 00:13:07.279 don't want to force a breaking change on people. We 224 00:13:07.360 --> 00:13:11.600 just want to strongly nudge you away, right. Yeah. 225 00:13:12.399 --> 00:13:16.000 Also, it's not as if those organizations aren't updating their 226 00:13:16.039 --> 00:13:19.080 own code. I mean, you know, if the project is dead, 227 00:13:19.120 --> 00:13:21.879 then it's dead. But you know, we are primarily talking 228 00:13:21.879 --> 00:13:26.840 about you know, living, not dead profitable. 229 00:13:27.159 --> 00:13:32.720 There's a difference between dead and it's not a suck 230 00:13:32.799 --> 00:13:36.000 of engineering resources every week, it's actually making money. 231 00:13:36.159 --> 00:13:38.679 Yeah, But in order to be profit afoodable these days, 232 00:13:38.679 --> 00:13:40.600 you need to be a service and the only way 233 00:13:40.639 --> 00:13:44.879 to justify being a service is continuously releasing updates even 234 00:13:44.879 --> 00:13:47.919 if nobody asks for them. 235 00:13:48.080 --> 00:13:51.639 Well, I was going to say one thing that circling back, 236 00:13:52.159 --> 00:13:55.600 I don't think I have seen anything breaking Node since 237 00:13:55.720 --> 00:13:59.799 version either ten or twelve. So I recently updated an application. 238 00:14:00.120 --> 00:14:02.919 Was so fraid because I'm actually using private APIs in 239 00:14:02.960 --> 00:14:06.440 the networking layer. I updated an application I think from 240 00:14:06.720 --> 00:14:09.759 it was version maybe twelve or fourteen, all the way 241 00:14:09.840 --> 00:14:15.120 up to version twenty, and there were no issues. So 242 00:14:15.600 --> 00:14:19.720 Note has become incredibly stable, probably after version I want 243 00:14:19.720 --> 00:14:21.200 to say after version ten. I think there was a 244 00:14:21.200 --> 00:14:23.799 ton of breaking changes in the version version six or eight, 245 00:14:24.399 --> 00:14:30.480 but version ten or twelve, it's it's been incredibly stable. 246 00:14:30.519 --> 00:14:34.679 In the likelihood that you'll have to go debug things 247 00:14:34.399 --> 00:14:37.879 is unless you're using an experimental feature. Ye had experimental flags, 248 00:14:37.879 --> 00:14:39.799 but even then, I don't think I've seen any breaks 249 00:14:39.799 --> 00:14:44.240 in the experimental features in the last several years. Few. 250 00:14:44.840 --> 00:14:46.879 Yeah, they're few, they count, you know, they're the usually 251 00:14:46.919 --> 00:14:48.919 pretty small, but they happen every now and then. 252 00:14:49.639 --> 00:14:52.240 One of the ones that I used, like fetch and 253 00:14:52.480 --> 00:14:56.879 the there was something in web crypto, and maybe there's 254 00:14:56.919 --> 00:14:59.039 some more niche things that are weird, like the U 255 00:15:00.200 --> 00:15:02.799 was that it's like a lifetimes thing. I forget what 256 00:15:02.799 --> 00:15:04.480 the name of it was, if I don't know if 257 00:15:04.480 --> 00:15:06.279 it's still a thing, but there was like some sort 258 00:15:06.320 --> 00:15:07.519 of a lifetimey thing. 259 00:15:08.639 --> 00:15:15.720 In price talking about Yeah, yeah. 260 00:15:13.799 --> 00:15:15.480 That might be. Like there's some of that stuff that 261 00:15:15.559 --> 00:15:18.159 was super experimental. I didn't touch, but anything that already 262 00:15:18.200 --> 00:15:20.159 had a web standard was the stuff that I was 263 00:15:20.919 --> 00:15:22.879 that I've been using that's been experimental. 264 00:15:23.679 --> 00:15:25.919 It's certainly like if you follow the discussions in the 265 00:15:26.000 --> 00:15:28.879 in the project, we really are careful about that and 266 00:15:28.919 --> 00:15:33.320 we think carefully. And you know, if even the ones 267 00:15:33.360 --> 00:15:35.799 that James mentioned, we do make some small breaking changes, 268 00:15:35.799 --> 00:15:37.360 but we think very carefully about those. 269 00:15:37.399 --> 00:15:38.960 We try and understand the impact. 270 00:15:39.039 --> 00:15:41.240 And so yeah, I think that's one of the things 271 00:15:41.240 --> 00:15:43.320 the project has been doing quite well over the last 272 00:15:43.399 --> 00:15:45.600 number of years is to try and minimize that. The 273 00:15:45.679 --> 00:15:47.440 other thing I wanted to add to what James was 274 00:15:47.480 --> 00:15:50.320 saying is like it really comes back to risk management. 275 00:15:52.000 --> 00:15:54.440 You know, you can continue to run on older versions, 276 00:15:54.639 --> 00:15:57.399 and I think if you've done your risk management, you've 277 00:15:57.399 --> 00:16:00.919 done your analysis, like you may you know, again back 278 00:16:00.919 --> 00:16:02.759 to your point of like it doesn't cost any money 279 00:16:02.799 --> 00:16:04.919 to leave it just running so that that isn't that 280 00:16:05.000 --> 00:16:07.000 is good and if you've actually thought about it, maybe 281 00:16:07.039 --> 00:16:09.720 you're doing the right thing. I think we just don't 282 00:16:09.720 --> 00:16:13.600 necessarily see that people are like thinking about it enough 283 00:16:13.679 --> 00:16:15.879 in terms of like should I should I have updated? 284 00:16:17.039 --> 00:16:19.039 You know, that's the easy answer is if you stay 285 00:16:19.039 --> 00:16:21.039 on the lift, you're going to get the security fixes 286 00:16:22.200 --> 00:16:24.519 or you know, there's some companies like like the one 287 00:16:24.519 --> 00:16:26.559 I work for that will give you longer term support, 288 00:16:26.679 --> 00:16:29.759 so you're probably okay then, But like we probably like 289 00:16:29.840 --> 00:16:33.639 to see a few more people either very carefully looking 290 00:16:33.639 --> 00:16:36.879 at their risks or sticking to the LTS releases and 291 00:16:36.879 --> 00:16:38.639 the ones that are active, because those are the ones 292 00:16:38.639 --> 00:16:40.000 that like the project is going to help. 293 00:16:40.559 --> 00:16:44.240 Yeah, but now you're starting to go towards the actual pillars, 294 00:16:44.799 --> 00:16:49.399 because that's literally one of the pillars. So I'll just 295 00:16:49.519 --> 00:16:52.600 pull us or push us towards that, and let's maybe 296 00:16:52.639 --> 00:16:55.120 start going down the pillars, unless you guys want to 297 00:16:55.159 --> 00:17:00.440 mention something else before we we do that, Okay, let's 298 00:17:00.480 --> 00:17:04.880 go do. Let's start with the pillars then, So pillar 299 00:17:04.960 --> 00:17:09.240 number one do not block the event loop. That's an 300 00:17:09.279 --> 00:17:13.359 interesting one because it's actually also very much pertinent to 301 00:17:13.640 --> 00:17:19.440 the browser, not only to node, and actually it's also 302 00:17:19.559 --> 00:17:23.759 pertinent to the Dino and bond. By the way, I 303 00:17:23.799 --> 00:17:26.799 will say that quite a number of these pillars are 304 00:17:26.880 --> 00:17:29.440 relevant or almost all of them are also relevant to 305 00:17:29.559 --> 00:17:33.880 Dino and to bon I think. And some of them 306 00:17:33.960 --> 00:17:38.079 are relevant, you know, to whatever server platform almost you're using. 307 00:17:38.359 --> 00:17:40.799 You know, they might be relevant if you're using Java 308 00:17:40.960 --> 00:17:45.759 or Go or whatever. But again we'll be focusing on 309 00:17:45.799 --> 00:17:49.720 a node in this conversation. So again, the first one 310 00:17:49.839 --> 00:17:53.440 is do not block the event loop. We've discussed the 311 00:17:53.440 --> 00:17:56.359 event loop in the past on this podcast, but maybe 312 00:17:56.400 --> 00:17:59.960 it's worthwhile for one of you guys to quickly explain 313 00:18:00.200 --> 00:18:02.920 reiterate what the event loop is and why it's so 314 00:18:02.960 --> 00:18:07.920 important not to block it. Yeah, I mean we can. 315 00:18:08.200 --> 00:18:11.039 We can talk about it just in very very high 316 00:18:11.079 --> 00:18:13.319 level general terms. You know, you know, the note has 317 00:18:13.359 --> 00:18:16.200 its event loop which is based on the UV. It 318 00:18:16.279 --> 00:18:22.160 is structured a particular way. Dino and and Bond and 319 00:18:22.440 --> 00:18:24.519 workers and stuff. We you know, they all have event 320 00:18:24.559 --> 00:18:28.400 loops that are that work slightly differently. They have different phases, 321 00:18:28.440 --> 00:18:31.640 different you know, slight you know, slightly different implementations, so 322 00:18:31.640 --> 00:18:34.400 they all work slightly differently. But they all have the 323 00:18:34.440 --> 00:18:37.799 same fundamental concept of it's going to be monitoring the 324 00:18:37.839 --> 00:18:41.160 system for we you know, certain events io, hey, I 325 00:18:41.160 --> 00:18:42.720 want to read a file, or I've got a network 326 00:18:42.759 --> 00:18:47.720 connection or whatever. And as it's turning, it's gonna you know, say, 327 00:18:48.200 --> 00:18:50.119 I gotta I got some io I'm going to fire 328 00:18:50.160 --> 00:18:52.200 a callback and that callback is going to go off 329 00:18:52.200 --> 00:18:55.680 and run some job script. And what's important to understand 330 00:18:56.119 --> 00:18:59.160 is that while that joba script is running, the event 331 00:18:59.200 --> 00:19:02.359 loop is not. It pauses while you go off and 332 00:19:02.440 --> 00:19:05.200 run that JavaScript, and then when that is done running, 333 00:19:05.240 --> 00:19:08.240 it comes back and the loop continues. It doesn't matter 334 00:19:08.240 --> 00:19:11.519 what platform you're on. That's how it works, unless you're 335 00:19:11.599 --> 00:19:14.759 using worker threads, which you have multiple event loops running 336 00:19:14.799 --> 00:19:18.880 on different threads. When you're whenever you're running JavaScript, nothing 337 00:19:18.920 --> 00:19:21.200 else is running, all right, You're not going out and 338 00:19:21.200 --> 00:19:23.839 pulling IOH, you're not looking for you know, you can't 339 00:19:23.920 --> 00:19:27.559 go off and accept the new connection that kind of stuff, right, 340 00:19:27.920 --> 00:19:31.640 So you know, it's you have to make sure that 341 00:19:31.640 --> 00:19:34.160 that jobscript that you're running can return fast enough for 342 00:19:34.200 --> 00:19:36.319 that event that to turn around and do something else. 343 00:19:38.440 --> 00:19:44.160 Now, on the browser side, it's it's maybe less catastrophic. 344 00:19:44.240 --> 00:19:47.079 But it's often more obvious when there's a problem with 345 00:19:47.160 --> 00:19:53.759 the event loop because user interactions starts to get jenky uh, 346 00:19:54.079 --> 00:19:59.240 somebody clicks a button and the UI doesn't respond because 347 00:19:59.400 --> 00:20:02.839 the browser is too busy processing the JavaScript for a 348 00:20:02.880 --> 00:20:08.400 previous event. What's the negative impact in node when you 349 00:20:09.559 --> 00:20:13.480 don't process stuff out of the event loop quickly enough, 350 00:20:13.599 --> 00:20:17.400 or when things stay in the queue for too long. 351 00:20:19.599 --> 00:20:22.920 I have a very nice talk on this, okay, which 352 00:20:22.960 --> 00:20:25.319 I recommend everybody to watch. I'm going to pass it. 353 00:20:25.640 --> 00:20:29.160 I'm going to summarize and then pass it into into 354 00:20:29.240 --> 00:20:35.160 the chat for everybody to to take a look. Okay, 355 00:20:35.599 --> 00:20:41.119 So the the gist is very simple. 356 00:20:41.200 --> 00:20:44.160 What is that? What happens? Okay? You take. 357 00:20:48.559 --> 00:20:52.279 Gets busy? Okay, the problem it doesn't? You say, well, 358 00:20:52.319 --> 00:20:54.559 the event top is busy. What problem it can be? 359 00:20:54.880 --> 00:20:55.200 Okay? 360 00:20:55.759 --> 00:21:01.039 Well, genetically, if there's only one user, and which is 361 00:21:01.079 --> 00:21:05.000 for example, the case for deployment on workers or in 362 00:21:05.480 --> 00:21:10.160 w islam DA, this is essentially the impact is very limited. 363 00:21:10.359 --> 00:21:10.680 Okay. 364 00:21:11.079 --> 00:21:13.720 However, you are also missing out on the key feature 365 00:21:13.839 --> 00:21:18.400 of no JS and zavaskipt itself because you can, you know, 366 00:21:18.480 --> 00:21:21.599 supporting multiples at the same time allow you to maximize 367 00:21:22.240 --> 00:21:24.079 the use of the source. 368 00:21:23.920 --> 00:21:25.480 Of that single process. 369 00:21:25.720 --> 00:21:30.680 So what happens is that once the amount of load 370 00:21:31.240 --> 00:21:33.599 goes over and there's a little bit of math involved, 371 00:21:33.920 --> 00:21:38.079 goes over a st threshold, the response time of your 372 00:21:38.079 --> 00:21:43.640 application will start getting will start looping into we start 373 00:21:43.680 --> 00:21:48.880 growing in an exponential in an exponential fashion, and therefore 374 00:21:49.279 --> 00:21:50.559 at that point. 375 00:21:50.359 --> 00:21:51.119 You are. 376 00:21:53.160 --> 00:21:57.200 Your application will stall completely, very quickly and not responding, 377 00:21:57.359 --> 00:22:02.640 not nothing, spinning wheels. Typically, the problem is if I 378 00:22:02.759 --> 00:22:04.519 send a request, okay. 379 00:22:04.480 --> 00:22:07.640 Do you. 380 00:22:06.359 --> 00:22:09.759 Want the if you're if you done a good job, 381 00:22:09.839 --> 00:22:12.799 you are going to respond. Your server is going to 382 00:22:12.799 --> 00:22:16.319 respond in I don't know, two und MILLI second a second, 383 00:22:16.559 --> 00:22:21.160 two second, okay, after what's the threshold after which I 384 00:22:21.240 --> 00:22:26.039 stop responding? Okay, I start I stopped waiting for a response, okay. 385 00:22:26.799 --> 00:22:30.359 But the problem is that when you receive an HTP request, 386 00:22:30.400 --> 00:22:34.200 you node you you know, not just as received that request, 387 00:22:34.640 --> 00:22:39.559 and we continue processing that request up independently of the 388 00:22:39.599 --> 00:22:45.640 fact that the user on the other end as he 389 00:22:45.720 --> 00:22:46.359 is still there. 390 00:22:46.759 --> 00:22:50.240 Okay. You can detect that. You can handle this with 391 00:22:50.279 --> 00:22:52.960 about signals and a bunch of other stuff, but it's 392 00:22:54.440 --> 00:22:57.799 definitely not definitely not common. 393 00:22:58.119 --> 00:23:01.799 Okay, So, and the genetic result is and when you know, 394 00:23:01.880 --> 00:23:04.240 gs reach a certain level of flow, it became very 395 00:23:04.319 --> 00:23:10.440 much unresponsible that your application became as andresponsive completely. 396 00:23:10.839 --> 00:23:13.559 And this is a massive, massive problem. 397 00:23:14.200 --> 00:23:17.880 A great example, you know, based on former customer, I'm 398 00:23:17.920 --> 00:23:19.759 not going to name any names and such, but we 399 00:23:20.079 --> 00:23:23.359 were called out to do some consulting work for them 400 00:23:23.359 --> 00:23:27.480 because their note application was very, very slow. They were 401 00:23:27.519 --> 00:23:31.400 getting a whopping four requests per second production, Like, what 402 00:23:31.440 --> 00:23:33.200 the hell are you doing to get only to only 403 00:23:33.279 --> 00:23:35.279 get four requests per second? Well, what they were. 404 00:23:35.160 --> 00:23:42.119 Doing apply to the trillions dig on every request almost worse. 405 00:23:42.200 --> 00:23:45.160 So, they were using an old version of Apollo that 406 00:23:45.319 --> 00:23:49.279 was not very performance optimized. Every graph COO career that 407 00:23:49.279 --> 00:23:52.599 they were received was very complex and it ended up 408 00:23:52.599 --> 00:23:55.240 being where they would do like ten to fifteen sub 409 00:23:55.240 --> 00:23:59.119 requests on that back in that back then, the way 410 00:23:59.160 --> 00:24:01.720 that propol works, it would receive the requests, it would 411 00:24:01.759 --> 00:24:05.039 parse it generate the AST, walk the AST, go off 412 00:24:05.079 --> 00:24:08.279 and submit all of the sub requests, wait for those 413 00:24:08.319 --> 00:24:10.599 to return, and then would have to go through and 414 00:24:10.640 --> 00:24:15.799 do this this process of reconstructing the response. Unfortunately, these 415 00:24:16.119 --> 00:24:18.799 queries were so complex that it was blocking the event 416 00:24:19.039 --> 00:24:23.559 All of that processing was was synchronous right now, Waiting 417 00:24:23.599 --> 00:24:26.359 on the sub requests that was asynchronous, but the actual 418 00:24:26.400 --> 00:24:28.839 parsing and walking to the AST was fully synchronous. And 419 00:24:28.839 --> 00:24:31.880 they were blocking the event loop from progressing every time 420 00:24:31.960 --> 00:24:35.559 that happened, and they were blocking it by so much 421 00:24:35.920 --> 00:24:38.279 that you know, it couldn't get around to take the 422 00:24:38.319 --> 00:24:39.359 next request. 423 00:24:39.640 --> 00:24:39.839 Right. 424 00:24:40.160 --> 00:24:43.119 The other problem that they were encountering though, is roughly 425 00:24:43.200 --> 00:24:47.039 maybe about fifteen percent of of their requests were failing 426 00:24:47.839 --> 00:24:51.319 with timeouts. And like you know, we'd understand why these 427 00:24:51.319 --> 00:24:54.319 are failing with timeouts. Well, what would happen is they 428 00:24:54.359 --> 00:24:57.640 would send, like I said, ten to fifteen back end requests, right, 429 00:24:59.039 --> 00:25:01.920 sub request those would go to the back end systems. 430 00:25:01.920 --> 00:25:08.200 Those systems were responding quickly, right and and you know, 431 00:25:08.279 --> 00:25:14.039 having responses pending in the IOQ in the node event loop. 432 00:25:14.440 --> 00:25:16.759 But if you look at the phases of the node 433 00:25:16.759 --> 00:25:20.720 event loop, what you'll see is almost right before we 434 00:25:20.759 --> 00:25:25.960 pull for pending io we checked timers, right, you know, 435 00:25:26.000 --> 00:25:29.160 and that loop we always checked timers first. What was 436 00:25:29.200 --> 00:25:31.720 happening is that the event loop was being blocked for 437 00:25:31.759 --> 00:25:35.160 so long that by the time the event loop turned 438 00:25:35.160 --> 00:25:38.880 and came to book the timers even though that those responses, 439 00:25:38.960 --> 00:25:42.319 the suber quest responses were waiting to be read, the 440 00:25:42.400 --> 00:25:45.720 timeouts on the sub requests would would fire and cancel 441 00:25:45.799 --> 00:25:49.720 the entire thing. Oh no, So it was just like 442 00:25:49.799 --> 00:25:54.480 this compounding problem that all of the synchronous activity blocking 443 00:25:54.519 --> 00:25:58.799 the loop from actually advancing IO tripping itself up. 444 00:26:00.559 --> 00:26:05.279 If I'm thinking about it, I can basically like perceive 445 00:26:05.359 --> 00:26:10.839 of two main problematic scenarios here and correct me if 446 00:26:10.880 --> 00:26:16.039 I'm if I'm wrong. One scenario is that even though 447 00:26:16.799 --> 00:26:24.039 events are are being handled relatively in a timely fashion individually, 448 00:26:24.880 --> 00:26:27.000 the rate in which they are coming in is so 449 00:26:27.200 --> 00:26:33.759 high that the server is simply unable to complete the 450 00:26:34.160 --> 00:26:36.799 processing the events at the rate that new events are 451 00:26:36.839 --> 00:26:41.799 coming in. That's that's problem number one. And problem number 452 00:26:41.880 --> 00:26:46.039 two is that regardless of the rate that events are 453 00:26:46.039 --> 00:26:50.839 coming in, sometimes the processing is so lengthy that the 454 00:26:50.920 --> 00:26:54.400 loop is just being blocked for so long that it's 455 00:26:54.440 --> 00:26:58.200 making the system and the system is unresponsive during that time. 456 00:26:58.599 --> 00:27:03.480 That that causes problems because other events time out are 457 00:27:03.480 --> 00:27:07.400 not processed in a sufficiently timely fashion, all sorts of problems. 458 00:27:07.720 --> 00:27:11.759 So the service might be even mostly not busy at all, 459 00:27:12.200 --> 00:27:15.960 but whenever something comes in, it just gets stuck for 460 00:27:17.079 --> 00:27:19.960 too long a period I understand. 461 00:27:19.640 --> 00:27:25.039 Incorrectly, yes, yes, yes, And if that event opens uppens 462 00:27:25.079 --> 00:27:28.160 too often, it gets into a catastrophic failure. 463 00:27:29.400 --> 00:27:32.839 And most as to say. 464 00:27:32.759 --> 00:27:35.960 Like the event loops really optimized to do lots of 465 00:27:36.079 --> 00:27:39.799 short things. And you know you talked about the first 466 00:27:39.839 --> 00:27:42.880 case of things coming in too quickly, Well, no one 467 00:27:42.920 --> 00:27:46.319 can scale to take a lot of incoming requests as 468 00:27:46.319 --> 00:27:49.000 long as you quickly hand them off to something else 469 00:27:49.039 --> 00:27:50.400 to like, you know, if you come in, you take 470 00:27:50.400 --> 00:27:52.680 a request, you hand it off to the database, and 471 00:27:52.759 --> 00:27:55.119 you do that asynchronously, it can scale to lots and 472 00:27:55.160 --> 00:27:57.759 lots of things coming in. I mean, I think it's 473 00:27:57.799 --> 00:28:00.680 a Mattel was kind of saying. But if you get 474 00:28:00.680 --> 00:28:03.079 to a point where you're you're trying to do too 475 00:28:03.119 --> 00:28:06.039 much in the event loop itself because you're you're effectively 476 00:28:06.079 --> 00:28:10.279 sharing a single thread, you're now going to slow everything down. 477 00:28:10.319 --> 00:28:13.079 And it follows over a cliff that at one point, 478 00:28:13.119 --> 00:28:15.680 so you know, if you've got longer running tasks, you 479 00:28:15.799 --> 00:28:17.759 really want to push them to worker threads. 480 00:28:18.359 --> 00:28:20.680 And a good example that I think is. 481 00:28:20.680 --> 00:28:25.680 More to or to other servers, but a microservices architecture 482 00:28:25.799 --> 00:28:27.119 something exactly. 483 00:28:27.519 --> 00:28:29.359 The one thing I think is kind of interesting is 484 00:28:29.359 --> 00:28:31.240 even if you have your micro service, you say, okay, 485 00:28:31.279 --> 00:28:33.119 I'm going to make a micro service for my very 486 00:28:33.160 --> 00:28:36.400 long running job, you still don't want to block the 487 00:28:36.400 --> 00:28:39.640 event loop for that micro service because the main event loop, 488 00:28:39.759 --> 00:28:43.160 because well, what if you deploy that micro service to Kubernetes. 489 00:28:43.599 --> 00:28:46.440 Kubernetes is probably going to have a liveness check, and well, 490 00:28:46.480 --> 00:28:48.240 how is that liveness check going to run? It's going 491 00:28:48.319 --> 00:28:50.079 to have to hit that main event loop and say hey, 492 00:28:50.160 --> 00:28:51.000 are you still alive? 493 00:28:51.799 --> 00:28:57.160 And sorry? I We literally had this problem, okay at 494 00:28:57.160 --> 00:29:00.000 the company that I worked at, again without naming names, 495 00:29:00.559 --> 00:29:08.519 we were actually using Prometheus, the Prometheus client, and without 496 00:29:08.559 --> 00:29:13.880 going into reasons, the Prometheus response that was being generated 497 00:29:14.039 --> 00:29:18.440 was huge, and it was a huge string being serialized 498 00:29:19.599 --> 00:29:23.559 and that just took too long. And if that happened 499 00:29:23.680 --> 00:29:27.480 while the liveness check happened to come in, it could 500 00:29:27.519 --> 00:29:31.440 literally cause the liveness check to time out and cause 501 00:29:31.599 --> 00:29:33.559 Kobernetes to kill that instance. 502 00:29:34.079 --> 00:29:37.799 Yeah, so you always want to push your long running 503 00:29:37.960 --> 00:29:41.279 jobs onto worker threads so that your main event luke 504 00:29:41.319 --> 00:29:42.480 can respond quickly. 505 00:29:44.880 --> 00:29:49.480 Yeah, and this problem is not unique to note, not 506 00:29:49.480 --> 00:29:52.319 by any stretch. Now, in other run times, it manifests 507 00:29:52.559 --> 00:29:55.920 differently like workers, and we have a completely different threading 508 00:29:55.920 --> 00:30:00.599 model and workers to note, every request is running on 509 00:30:00.599 --> 00:30:03.559 its own thread coming in. We can still accept other 510 00:30:03.599 --> 00:30:07.440 requests and that kind of thing, but and isolate, a 511 00:30:07.519 --> 00:30:11.640 particular worker might be used by multiple threads. So whenever 512 00:30:11.920 --> 00:30:16.200 one request is being processed on one thread, right, no 513 00:30:16.359 --> 00:30:19.680 other threads can use that isolate, that can can use that, 514 00:30:19.799 --> 00:30:22.200 you know, that particular instance. And we have to share these. 515 00:30:22.599 --> 00:30:24.119 So we have these things that are all you know, 516 00:30:24.160 --> 00:30:27.039 basically lock contention. It's waiting for that locks, you know, 517 00:30:27.079 --> 00:30:28.960 waiting for that isolate to be free so I can 518 00:30:29.039 --> 00:30:31.519 use it on this particular thread and it jumps around 519 00:30:31.880 --> 00:30:35.799 the effect. It's a different mechanism but has the same 520 00:30:35.960 --> 00:30:39.880 effect of blocking other things. If one particular request has 521 00:30:39.960 --> 00:30:42.880 too much synchronous processing, it goes on for too long, 522 00:30:43.720 --> 00:30:47.759 then other threads can't acquire that lock and can't progress, 523 00:30:47.839 --> 00:30:50.279 They can't you know, run their own jobscript and it 524 00:30:50.359 --> 00:30:52.559 ends up being the same basic effects blocking the note 525 00:30:52.559 --> 00:30:53.039 event loop. 526 00:30:54.480 --> 00:30:59.319 So you just sorry, you just just that I'm not 527 00:30:59.440 --> 00:31:03.000 used to thinking about blocks soften in the context of JavaScript. 528 00:31:03.160 --> 00:31:04.240 That's all I wanted to say. 529 00:31:05.359 --> 00:31:07.519 Yeah, I mean, but they're there, you know, And in 530 00:31:07.920 --> 00:31:11.519 the key concept here for this particular pillar is yes, 531 00:31:11.599 --> 00:31:13.559 run jobscript all you want, just do it in short 532 00:31:13.640 --> 00:31:18.640 span you know, first, don't do these huge, long, secretus processes. 533 00:31:19.599 --> 00:31:24.559 So basically, either push processing off of the main note 534 00:31:26.720 --> 00:31:32.400 thread to workers, to micro services whatever, don't and don't 535 00:31:32.519 --> 00:31:34.680 wait on them, just send it and wait for their 536 00:31:34.720 --> 00:31:42.799 synchronous response. Or break your long running JavaScript into multiple 537 00:31:42.960 --> 00:31:48.640 shorter segments might see anything, you know, the set time 538 00:31:48.720 --> 00:31:53.160 out zero for the wind. 539 00:31:51.799 --> 00:31:53.960 Typically the task the company. 540 00:31:55.559 --> 00:31:59.200 But yes, unfortunately, yes, okay, in that way, other things 541 00:31:59.279 --> 00:32:00.519 can be scheduled in between. 542 00:32:01.160 --> 00:32:04.119 Okay, So that's the gist. 543 00:32:04.279 --> 00:32:07.000 But genetically, I would say that we do have enough 544 00:32:07.400 --> 00:32:11.160 technologies right now to run things easily on worker threads 545 00:32:11.279 --> 00:32:15.000 that you should just be using trads like literally, most 546 00:32:15.039 --> 00:32:16.359 developers don't think. 547 00:32:18.119 --> 00:32:20.839 That no JS is multi threaded these days. 548 00:32:21.079 --> 00:32:24.480 It has been since twenty eighteen, and most developers since 549 00:32:24.680 --> 00:32:27.519 you know, they're still reading that tutorial from twenty fifteen. 550 00:32:28.079 --> 00:32:32.359 So that's a problem. 551 00:32:33.599 --> 00:32:36.279 I have to say that there is one issue with it, 552 00:32:37.160 --> 00:32:39.599 and I know that there are several proposals that are 553 00:32:39.680 --> 00:32:42.160 looking to address it, but so far it still exists, 554 00:32:42.240 --> 00:32:45.599 and it's more of a JavaScript issue than a note issue, 555 00:32:46.119 --> 00:32:52.799 and it's that serializing stuff across workers can be sometimes 556 00:32:52.920 --> 00:32:57.319 more expensive that the actual work that was offloaded. Like 557 00:32:57.519 --> 00:33:01.519 serializing and de serializing each way can sometimes be more 558 00:33:01.559 --> 00:33:04.279 expensive than the actual work that you're afloaded if you're 559 00:33:04.319 --> 00:33:05.240 not careful. 560 00:33:05.200 --> 00:33:07.920 Of course, but it means that you need to upfload 561 00:33:08.000 --> 00:33:09.960 staff that is beer essentially. 562 00:33:10.720 --> 00:33:13.000 Yeah, yeah, and there are ways around that, you know, 563 00:33:13.079 --> 00:33:15.759 with with you know, my shared array offfer and some 564 00:33:15.880 --> 00:33:17.079 of the shared data structures we have. 565 00:33:17.240 --> 00:33:18.000 So yeah. 566 00:33:19.200 --> 00:33:24.799 So Node has the ability to run multiple processes, so 567 00:33:24.920 --> 00:33:27.519 you can you can fork, and you can I don't 568 00:33:27.519 --> 00:33:31.000 remember exactly. I kind of forgot it because it turned 569 00:33:31.000 --> 00:33:33.039 out not to be useful for this very reason that 570 00:33:33.200 --> 00:33:38.119 the the communication between Node processes of doing the Jason 571 00:33:38.160 --> 00:33:41.519 stringifying the Jason parse makes it so that you should 572 00:33:41.599 --> 00:33:44.440 probably never ever do that. And the only way that 573 00:33:44.480 --> 00:33:46.599 you should be using Node if you're going to use 574 00:33:46.640 --> 00:33:49.680 multiple processes, not it is not it's it's child process 575 00:33:49.759 --> 00:33:53.960 forking mechanism, but rather you just run multiple processes. They 576 00:33:54.000 --> 00:33:58.400 handle all multiple requests and let them you know, donect 577 00:33:58.440 --> 00:34:01.440 to the database, separate and stuff. Yeah, well where would 578 00:34:01.480 --> 00:34:06.039 that where would that be profitable? Where? Where would it 579 00:34:06.160 --> 00:34:10.000 actually make sense to use that? Oh, cluster, it's called 580 00:34:10.039 --> 00:34:14.119 node cluster, right, yeah, is that what it's called. Yeah, yeah, 581 00:34:14.239 --> 00:34:15.920 so I think it's kind of a secure feature most 582 00:34:15.920 --> 00:34:20.039 people know about. Yeah, I think today what we're doing good. 583 00:34:20.639 --> 00:34:22.519 I was going to say today, I would defer to 584 00:34:22.800 --> 00:34:26.480 other things, Like you know, Kubernetes will manage multiple instances 585 00:34:26.519 --> 00:34:29.760 of your node application, each which should be stateless. So 586 00:34:29.920 --> 00:34:32.199 like if you want to scale, there's lots of non 587 00:34:32.320 --> 00:34:35.239 node specific ways of scaling processes out, so you can 588 00:34:35.280 --> 00:34:38.960 have multiple compaties of your your microwins, of your micro service. 589 00:34:39.000 --> 00:34:40.800 So that's why I wouldn't necessarily be using the cluster 590 00:34:40.920 --> 00:34:45.840 module on its own anymore. So it's really like, you know, 591 00:34:45.960 --> 00:34:48.880 I would typically scale using those technologies when it's a 592 00:34:48.960 --> 00:34:51.760 matter of just needing more than one thread's worth worth 593 00:34:51.840 --> 00:34:55.639 of you know, throughput, because you could have lots of 594 00:34:55.679 --> 00:34:58.039 little tasks, but you just still can't handle all those 595 00:34:58.119 --> 00:35:00.519 tasks on a single thread, in which case let's scale 596 00:35:00.559 --> 00:35:04.280 out to multiple processes. But if you have long running tasks. 597 00:35:04.599 --> 00:35:07.920 Even if you have enough to maybe only take fifty 598 00:35:07.960 --> 00:35:10.360 percent of your single CPU, you don't want to do 599 00:35:10.519 --> 00:35:12.760 those on your main thread loop. You want to still 600 00:35:12.800 --> 00:35:15.239 push those two workers because you don't want to be 601 00:35:15.280 --> 00:35:17.840 blocking all the all the work based on those lower 602 00:35:18.119 --> 00:35:20.280 or longer transactions, right, even if there's like one in 603 00:35:20.440 --> 00:35:24.400 ten every tenth second, you don't want to have something 604 00:35:24.440 --> 00:35:26.800 that takes a really long time and slows everybody. Yeah. 605 00:35:26.840 --> 00:35:28.840 I think it was Jake Archibald that said it in 606 00:35:28.960 --> 00:35:31.480 the context, or maybe it was a Somat that said 607 00:35:31.519 --> 00:35:33.519 it in the context of browsers that one of the 608 00:35:33.599 --> 00:35:36.840 reasons that you want to offload things to workers is 609 00:35:36.920 --> 00:35:41.159 not so much sorry about performance, it's more about consistency. 610 00:35:42.760 --> 00:35:45.480 That you don't want all of the like every x 611 00:35:45.639 --> 00:35:49.440 task to suddenly block your system for too long. I 612 00:35:49.559 --> 00:35:51.800 do have to say though, that in my experience, most 613 00:35:51.840 --> 00:35:54.239 of the work that I've seen done on loade is 614 00:35:54.360 --> 00:35:58.599 mostly as quote unquote middleware, so very often there's not 615 00:35:58.880 --> 00:36:04.239 so much heavy lifting being done inside the note service itself. 616 00:36:04.599 --> 00:36:05.519 Let's say it this way. 617 00:36:05.920 --> 00:36:06.719 Are you sure done? 618 00:36:08.360 --> 00:36:10.360 No, I'm not. I'm scared. 619 00:36:10.920 --> 00:36:14.079 Let's let if you if you take a look at 620 00:36:14.280 --> 00:36:19.719 what the all the front end meta frameworks are doing lately. 621 00:36:20.320 --> 00:36:26.480 They all of them, they are massively blocking the develope 622 00:36:27.280 --> 00:36:27.760 like they. 623 00:36:30.000 --> 00:36:33.599 All of the rendering code, the service rendering stuff. 624 00:36:33.920 --> 00:36:37.639 Yes, so in that scenario, if you are already I 625 00:36:37.719 --> 00:36:41.960 have a very expensive rendering pipeline and you also need 626 00:36:42.000 --> 00:36:46.039 to do some data processing, data mangling that can take 627 00:36:46.119 --> 00:36:47.000 some CPU. 628 00:36:46.800 --> 00:36:50.960 Time, you are really really you really really want to 629 00:36:51.000 --> 00:36:56.079 push it somewhere else. Okay, and you do well, not 630 00:36:56.320 --> 00:36:59.119 on the not on the tutorials, but yeah, you can 631 00:37:00.119 --> 00:37:01.599 not on their maint not on the mein. 632 00:37:01.559 --> 00:37:04.480 To No, I'm asking if from your experience, the framework 633 00:37:04.599 --> 00:37:10.320 makers are doing the the best, you know, the best 634 00:37:10.360 --> 00:37:12.320 that they could do to offload stuff. 635 00:37:12.519 --> 00:37:15.719 You know, they are in order to turn it better. 636 00:37:16.360 --> 00:37:19.000 It's getting better and better and better. And I think 637 00:37:19.119 --> 00:37:21.960 it's it's not like a lot of it comes around 638 00:37:22.320 --> 00:37:26.559 on the marketing side versus the framework itself. Okay, then 639 00:37:26.840 --> 00:37:29.639 nothing in the frameworks blocks you to do certain things, okay, 640 00:37:30.119 --> 00:37:33.599 But it's more about how they market they frameworks and 641 00:37:33.639 --> 00:37:40.960 the products that cause, like the they make, the they 642 00:37:41.039 --> 00:37:44.960 make those applications. You know, they teach developers using their 643 00:37:45.000 --> 00:37:49.440 frameworks very often that they could do certain things, and 644 00:37:49.599 --> 00:37:52.480 those certain things will work very well up until a point, 645 00:37:53.039 --> 00:37:54.840 and then they won't work anymore. 646 00:37:55.320 --> 00:37:57.159 But they then don't tell you that point. 647 00:37:57.880 --> 00:38:01.119 Yeah, and the promotereos example I think I gave is 648 00:38:01.280 --> 00:38:03.000 a pretty good representation of that. 649 00:38:03.840 --> 00:38:04.800 Yeah for that. 650 00:38:05.079 --> 00:38:07.960 Okay, what we have recently been done and we have 651 00:38:08.039 --> 00:38:11.000 losen as a product called the VA Application Server. And 652 00:38:11.159 --> 00:38:15.000 what we do is we keep we use one work thread, 653 00:38:15.480 --> 00:38:18.440 so we run the applications in the application in a 654 00:38:18.480 --> 00:38:21.920 worker thread and we keep the prometheus in the main thread. 655 00:38:22.440 --> 00:38:26.239 So in this way we can have the monitor okay, 656 00:38:27.639 --> 00:38:33.280 not affected by the application itself. And in this way 657 00:38:33.519 --> 00:38:34.639 you can keep things. 658 00:38:35.440 --> 00:38:40.000 We can keep things responsive and app okay and be 659 00:38:40.079 --> 00:38:43.119 able to monitor them correctly even if the application is 660 00:38:43.239 --> 00:38:43.960 under eavylod. 661 00:38:46.119 --> 00:38:48.719 Yeah. By the way, just to toot my own horn, 662 00:38:48.840 --> 00:38:52.320 I actually contributed back into the prompt client project and 663 00:38:52.400 --> 00:38:57.519 optimization that basically just reduced the runtime cost of serializing 664 00:38:57.599 --> 00:39:00.519 the string by something like fifty percent. Uh. 665 00:39:02.119 --> 00:39:04.559 That serialization thing, and going back to you know it 666 00:39:04.800 --> 00:39:08.559 is you know original point there about the cost of 667 00:39:09.000 --> 00:39:11.840 serializing the data back and forth across these boundaries, right, 668 00:39:11.920 --> 00:39:13.320 you know, it doesn't matter if you're using a worker 669 00:39:13.360 --> 00:39:17.119 thread or a child process or whatever, I PC doesn't matter. 670 00:39:17.639 --> 00:39:20.679 The serialization and de serialization back and forth those boundaries 671 00:39:20.800 --> 00:39:24.119 always has a cost. You can use you know, faster 672 00:39:24.480 --> 00:39:27.719 serialization framework so proto buff or cat and P versus, 673 00:39:27.840 --> 00:39:31.320 you know, instead of serializing everything as is JSON, but 674 00:39:31.440 --> 00:39:34.239 you're still going to have a cost. So it's like 675 00:39:34.320 --> 00:39:38.239 anytime you're you're distributing this load you need to do, 676 00:39:38.519 --> 00:39:41.039 you take effort, takes steps to minimize the amount of 677 00:39:41.079 --> 00:39:43.280 serialization de serialization you're going to do. You're using a 678 00:39:43.360 --> 00:39:46.679 child process rather than sending a large chunk of JSON 679 00:39:47.480 --> 00:39:50.039 just past the FD right and let the let that 680 00:39:50.159 --> 00:39:52.480 child process you know, read the data off the off 681 00:39:52.519 --> 00:39:54.599 the network and do its own you know, don't parts 682 00:39:54.960 --> 00:39:58.880 or whatever. If you're doing worker threads, use shared data 683 00:39:58.920 --> 00:40:01.679 objects like shared rape buffer rather than things that need 684 00:40:01.760 --> 00:40:06.079 to get copied and serialized using structured clone. The more 685 00:40:06.599 --> 00:40:08.400 of those kinds of things you do, the more effective 686 00:40:08.599 --> 00:40:12.239 this this load distribution is going to be because you're 687 00:40:12.280 --> 00:40:13.719 not going to eat the you know, eat up all 688 00:40:13.760 --> 00:40:17.360 your your performance gain on serialization de serialization costs. 689 00:40:19.519 --> 00:40:22.239 Well, we've been stuck on the first pillar for such 690 00:40:22.239 --> 00:40:24.320 a long time, it's pretty obvious we won't be able 691 00:40:24.400 --> 00:40:26.679 to run through all the pillars, which is just a 692 00:40:26.760 --> 00:40:31.079 great excuse to invite you all over again. But still, 693 00:40:31.239 --> 00:40:34.360 unless somebody else wants to say something about the first pillar, 694 00:40:34.760 --> 00:40:36.800 I think we'll move on to the second one. Is 695 00:40:36.840 --> 00:40:37.480 that okay with it? 696 00:40:37.519 --> 00:40:39.559 I think we have covered the second one too. 697 00:40:39.559 --> 00:40:39.760 You know. 698 00:40:41.880 --> 00:40:44.679 Yeah, so an extent we have. It's a monitor note 699 00:40:44.719 --> 00:40:47.559 specific metrics and act on them. This is one of 700 00:40:47.639 --> 00:40:51.719 those recommendations which is true everywhere, for every system, not 701 00:40:52.000 --> 00:40:54.880 just for Note. I will say that I'll be monitoring. 702 00:40:55.559 --> 00:40:59.800 Yeah, there's there's one here that is worth calling out. 703 00:41:00.199 --> 00:41:03.159 Most people, most new users, even even the long terms, 704 00:41:03.320 --> 00:41:07.679 aren't familiar with event loop utilization. Folks still talk about 705 00:41:07.719 --> 00:41:11.519 event loop delay, right, and that is a different metric. 706 00:41:12.039 --> 00:41:15.880 Event look utilization is a relatively new concept. It's been 707 00:41:15.920 --> 00:41:17.719 there for a couple of years. Most people don't know. 708 00:41:17.719 --> 00:41:21.719 About it, and it's amazing. James maybe four. 709 00:41:21.920 --> 00:41:22.119 Yeah. 710 00:41:23.199 --> 00:41:27.280 The evently utilization is a measurement of how effectively your 711 00:41:27.880 --> 00:41:31.800 event loop is processing tasks versus waiting for things. 712 00:41:32.480 --> 00:41:32.559 Uh. 713 00:41:32.599 --> 00:41:35.960 And it's it's a much more accurate metric of how 714 00:41:36.920 --> 00:41:40.079 well your application is performing than event loop delay, so 715 00:41:40.400 --> 00:41:43.360 everyone should continue. 716 00:41:44.159 --> 00:41:47.320 Yeah, because I would like you to explain it. I'm 717 00:41:47.440 --> 00:41:50.639 familiar with the term with a metric called event loop lag. 718 00:41:50.960 --> 00:41:53.679 Is that just an alternate name for event loop delay? 719 00:41:54.639 --> 00:41:56.639 Yeah, that I would think so. 720 00:41:56.800 --> 00:42:02.360 Yeah, so event loop, which I knew was basically what 721 00:42:02.480 --> 00:42:06.599 you described. It's like looking at the meantime or the 722 00:42:06.719 --> 00:42:11.440 ninetieth percentile between when an event gets into the queue 723 00:42:11.800 --> 00:42:14.719 and until it gets processed pulled from the queue in 724 00:42:14.840 --> 00:42:18.440 order to be processed. And obviously they're the statement was 725 00:42:19.159 --> 00:42:21.400 you know, you want the mean value or the ninetieth 726 00:42:21.440 --> 00:42:25.280 percentile or whatever to be basically as low as possible 727 00:42:25.599 --> 00:42:27.800 in order for the system to be responsible. But you're 728 00:42:27.880 --> 00:42:31.519 talking about something else. You're talking about event loop utilization. 729 00:42:31.719 --> 00:42:33.400 Can you explain that metric to us. 730 00:42:34.920 --> 00:42:37.360 Yeah, I mean there's a few things Ago went to it, 731 00:42:37.480 --> 00:42:41.079 but it's basically a ratio of how how much time 732 00:42:41.639 --> 00:42:46.239 your event loop is spending doing things versus just sitting 733 00:42:46.280 --> 00:42:49.639 idle waiting for things. So let's say if you have 734 00:42:50.079 --> 00:42:52.840 an event loop that is just going off, your application 735 00:42:53.000 --> 00:42:55.320 is just going up and scheduling a whole bunch of IYO, 736 00:42:56.159 --> 00:42:57.599 and then it has to wait a long time for 737 00:42:57.679 --> 00:43:00.599 that io to do anything, and in between as times 738 00:43:00.960 --> 00:43:05.800 it's not actually processing anything else. Right, In that case, 739 00:43:05.880 --> 00:43:10.159 your event loop is not being utilized effectively. It's spending 740 00:43:10.199 --> 00:43:13.480 most of this time being idle waiting for stuff. But 741 00:43:13.559 --> 00:43:16.440 if that event loop is able to turn over very 742 00:43:16.519 --> 00:43:19.000 very quickly accept a new request, except a new request 743 00:43:19.159 --> 00:43:23.039 while it's processing other things while it's waiting for that 744 00:43:23.159 --> 00:43:26.000 other step to happen, if it's able to keep processing things, 745 00:43:26.039 --> 00:43:28.920 then you're going to see a higher utilization. That basically 746 00:43:29.000 --> 00:43:35.039 means your event loop is doing more more efficiently. I 747 00:43:35.119 --> 00:43:37.519 hope that's there's a whole paper. 748 00:43:37.320 --> 00:43:40.679 On it, Okay, but I'd be happy to have a 749 00:43:40.760 --> 00:43:43.519 link to that paper. But one thing does concern me. 750 00:43:43.639 --> 00:43:46.239 It does seem that if I pull in like the 751 00:43:46.320 --> 00:43:51.639 first event, and that triggers an infinite computation, which means 752 00:43:51.719 --> 00:43:54.679 all the other things are just stuck in the queue forever, 753 00:43:55.320 --> 00:43:59.000 my event loop utilization would still appear to be great 754 00:43:59.199 --> 00:44:01.840 because I'm just processing forever. 755 00:44:02.079 --> 00:44:05.000 Like is that more? 756 00:44:05.000 --> 00:44:06.039 Am I missing something? 757 00:44:07.000 --> 00:44:09.760 Yeah? Missing some of the details. It takes some of 758 00:44:09.840 --> 00:44:12.920 those those things into consideration. The paper goes into a 759 00:44:12.960 --> 00:44:15.880 lot more detail, and this was done by trepreneurs at 760 00:44:15.960 --> 00:44:19.360 notes source that the blog post he wrote on this 761 00:44:19.480 --> 00:44:23.599 initially introducing it answers pretty much all the questions about it. 762 00:44:24.320 --> 00:44:27.159 It is one of the best research you. 763 00:44:27.239 --> 00:44:32.239 Can You can take event loubutalization and in a slightly 764 00:44:32.320 --> 00:44:36.159 different way. Okay, consider this an event look delay or 765 00:44:36.199 --> 00:44:36.880 event look blog. 766 00:44:37.079 --> 00:44:41.639 Okay. It's a metric okay that you can measure after 767 00:44:41.800 --> 00:44:42.480 there is a lag. 768 00:44:43.039 --> 00:44:47.079 Okay, however, you only have a lag okay if your 769 00:44:47.159 --> 00:44:53.000 event loop is very busy, correct, Okay. Event loopertilization is 770 00:44:53.079 --> 00:44:56.239 able to tell you that the event your event loop 771 00:44:56.320 --> 00:44:59.400 is getting busy, so you can act on it way 772 00:44:59.559 --> 00:45:04.119 sooner then the event loop at Okay. 773 00:45:04.679 --> 00:45:05.880 In fact, is it much. 774 00:45:05.800 --> 00:45:09.360 Basically what you're saying. What you're saying. If I'm taking 775 00:45:09.440 --> 00:45:12.519 too long to process user requests, but I have very 776 00:45:12.599 --> 00:45:15.920 few users, then I might not notice that I have 777 00:45:16.039 --> 00:45:18.800 a problem, and by the time I do realize I 778 00:45:18.840 --> 00:45:21.000 have a problem, it's kind of too late in a 779 00:45:21.119 --> 00:45:24.880 sense because users are already suffering. What you're saying is 780 00:45:24.960 --> 00:45:29.559 with event loop utilization, I'll be noticing it much earlier 781 00:45:30.079 --> 00:45:33.039 and be able to respond to it, you know, in advance. 782 00:45:33.280 --> 00:45:36.199 It's really interesting I very much would like to look 783 00:45:36.239 --> 00:45:38.159 at the paper it's. 784 00:45:40.239 --> 00:45:42.880 It does. Go ahead, and I'll just mentioned real quick. 785 00:45:42.880 --> 00:45:44.519 The other thing that it does is it tells you 786 00:45:44.639 --> 00:45:47.280 how well you're scaling, and it gives you a much 787 00:45:47.320 --> 00:45:51.119 more accurate scaling point. So a lot of applications previously 788 00:45:51.159 --> 00:45:55.000 would look at CPU usage right and when when Note 789 00:45:55.039 --> 00:45:59.039 process is primarily just one thread, one main application thread. 790 00:45:59.079 --> 00:46:03.440 Before we had worker threads, that was an okay measurement, 791 00:46:03.519 --> 00:46:05.480 but it was still pretty noisy. As soon as we 792 00:46:05.519 --> 00:46:08.599 introduced worker threads, the CPU monitoring just goes out the 793 00:46:08.639 --> 00:46:10.880 window because it becomes way too noisy because you're you know, 794 00:46:10.960 --> 00:46:13.880 because it's it's not fine grained enough to be able 795 00:46:13.920 --> 00:46:20.480 to show you individual event loop processes. Uh. The event 796 00:46:20.519 --> 00:46:24.639 look utilization is per event loop, so it's per worker thread, 797 00:46:24.719 --> 00:46:27.679 and it gives you a much better signal at where 798 00:46:27.760 --> 00:46:29.960 you where and when you need to start scaling your 799 00:46:30.000 --> 00:46:35.280 application to multiple processes and multiple worker threads. Uh. You know, 800 00:46:35.440 --> 00:46:37.559 you know, better than any other metric that I've seen, 801 00:46:37.679 --> 00:46:39.480 this is the one that gives you the best, the 802 00:46:39.840 --> 00:46:40.960 best accuracy for that. 803 00:46:41.880 --> 00:46:46.000 And monitoring systems these days do they expose this metric. 804 00:46:48.000 --> 00:46:48.199 Well. 805 00:46:48.239 --> 00:46:54.079 Plus formatting does so. Sorry for the for the pon here, 806 00:46:54.400 --> 00:46:59.039 but yeah, we would product our product absolutely, but also 807 00:46:59.159 --> 00:47:02.079 all our open source expose this metric on as part 808 00:47:02.199 --> 00:47:06.519 of the promissious integration, so you can essentially take it 809 00:47:06.639 --> 00:47:08.559 and consume it and so on and sup forth. The 810 00:47:08.639 --> 00:47:11.880 important part is that you want you want to set 811 00:47:11.920 --> 00:47:16.320 your out of scale to uh, look at this metric 812 00:47:16.519 --> 00:47:21.239 versus CPU. Okay, if you if you look at CPU usage, 813 00:47:21.360 --> 00:47:23.480 you are typically is too luggy. 814 00:47:23.920 --> 00:47:24.239 Okay. 815 00:47:24.960 --> 00:47:28.480 Once, once you see once the horizontal product of scaler 816 00:47:28.639 --> 00:47:31.800 see that stuff, you are you are already in trouble. 817 00:47:31.960 --> 00:47:32.280 Okay. 818 00:47:34.360 --> 00:47:37.480 But it's not a metric that's built into no or whatever. 819 00:47:37.639 --> 00:47:41.559 There's no like no evens there's an API board. Yeah, 820 00:47:42.039 --> 00:47:44.400 there's an a p I built into it directly in 821 00:47:44.440 --> 00:47:46.480 the it's part of the perfect. 822 00:47:46.159 --> 00:47:48.159 Say you need to enable it in from client. 823 00:47:49.840 --> 00:47:52.920 Very cool, very cool. We'll definitely look at it. Thank 824 00:47:52.960 --> 00:47:59.800 you for that. Anything else about pillar number two? Okay, 825 00:47:59.840 --> 00:48:03.440 the and moving on to pillar number three news node 826 00:48:03.679 --> 00:48:08.119 LTS versions in production. I think it even though people 827 00:48:08.199 --> 00:48:10.920 listening to us should be familiar with node, I think 828 00:48:11.000 --> 00:48:14.960 it's worthwhile to mention what node LTS versions actually mean. 829 00:48:17.559 --> 00:48:18.960 Yeah, long term supports. 830 00:48:19.239 --> 00:48:23.000 Basically, Michael, you want to take it, sure, Yeah, like 831 00:48:23.119 --> 00:48:28.039 long you can go to the website on the GitHub. 832 00:48:28.280 --> 00:48:31.159 It's like no gs slash release, it'll have our schedule 833 00:48:31.920 --> 00:48:37.519 the you know, every it's very predictable release schedule. We 834 00:48:37.639 --> 00:48:41.480 have a current which happens every April and October, and 835 00:48:41.559 --> 00:48:44.559 then every even current gets promoted to long term support. 836 00:48:44.559 --> 00:48:46.639 And long term support means I think it's thirty months 837 00:48:46.679 --> 00:48:49.800 of support, so it lasts from you know, October this 838 00:48:50.000 --> 00:48:53.199 year for example, to April two and a half years 839 00:48:53.239 --> 00:48:58.440 from now, and so the odd currents they only have 840 00:48:58.519 --> 00:49:00.960 six months of support. So you know why we say 841 00:49:01.000 --> 00:49:02.840 you really want to stick to the long term support 842 00:49:03.039 --> 00:49:06.159 versions is that you know, that's the longest period of 843 00:49:06.239 --> 00:49:08.800 time that you can sort of be on a version 844 00:49:08.880 --> 00:49:11.239 that's not going to go out of service. And back 845 00:49:11.280 --> 00:49:13.159 to AG's point of like, we don't want to change 846 00:49:13.199 --> 00:49:16.320 things any anytime. We don't want to change them because 847 00:49:16.320 --> 00:49:19.039 it costs us money, right, So you want to basically 848 00:49:19.440 --> 00:49:22.000 look at the release schedule and pet the LTS. 849 00:49:22.119 --> 00:49:23.679 It's going to give you the longest runway. 850 00:49:25.199 --> 00:49:28.559 And you know, I'd also say, like schedule, you don't 851 00:49:28.599 --> 00:49:30.679 have to move up to every LTS because we have 852 00:49:30.960 --> 00:49:33.679 multiple overlapping LTS is we either have like two or 853 00:49:33.719 --> 00:49:36.519 three usually going on at the same time. So if 854 00:49:36.519 --> 00:49:38.960 it was me, I would basically say, like, okay, when 855 00:49:39.000 --> 00:49:40.760 am I want to go into production, let's plan to 856 00:49:40.800 --> 00:49:44.440 have the closest LTS and then you know, two years 857 00:49:44.519 --> 00:49:47.480 later I should plan on like, okay, now let's plan 858 00:49:47.639 --> 00:49:50.960 for upgrading that particular version of the next LTS. There 859 00:49:51.000 --> 00:49:53.639 are multiple phases in LTS as well. There's like an 860 00:49:53.719 --> 00:49:57.519 active phase where we backport changes quite quickly, so if 861 00:49:57.559 --> 00:49:59.320 you want to get new features, they still go into 862 00:49:59.360 --> 00:50:04.679 those LTS releases, but about after the first and I'm 863 00:50:04.880 --> 00:50:08.559 thinking it's eight months ish now I'd have to look 864 00:50:08.639 --> 00:50:12.000 exactly at the numbers. It then flips into maintenance, where 865 00:50:12.119 --> 00:50:15.519 things are more like as needed security, security fixes, that 866 00:50:15.719 --> 00:50:16.239 kind of stuff. 867 00:50:17.519 --> 00:50:21.400 Why do non LTS versions even exist and why would 868 00:50:21.480 --> 00:50:23.039 I ever use one of them? 869 00:50:23.400 --> 00:50:25.719 See that there are people who want to be on 870 00:50:25.840 --> 00:50:29.920 the bleeding edge, and so those ones give you based 871 00:50:29.960 --> 00:50:31.840 on our schedule. 872 00:50:31.960 --> 00:50:33.800 We feed things into those non. 873 00:50:33.760 --> 00:50:35.880 LTS versions first, so if you want to get the 874 00:50:36.079 --> 00:50:39.239 very latest, greatest, you can try them out there, and 875 00:50:39.320 --> 00:50:41.719 we do appreciate that people test them out for us 876 00:50:41.800 --> 00:50:44.239 and give us feedback. And you know, so if you 877 00:50:44.280 --> 00:50:47.039 want to take advantage of a new feature, we really do. 878 00:50:47.159 --> 00:50:49.679 People want want people to try those out and give 879 00:50:49.760 --> 00:50:50.800 us that early feedback. 880 00:50:51.639 --> 00:50:54.760 And there have been cases were I've there have been 881 00:50:54.800 --> 00:50:57.840 cases where I've had to use a non LTS because 882 00:50:57.880 --> 00:51:01.400 there was a critical feature particular related to web crypto 883 00:51:01.920 --> 00:51:06.880 or fetch or one of those standards that is cross 884 00:51:07.800 --> 00:51:12.119 platform standard for JavaScript that was only available first in 885 00:51:12.239 --> 00:51:16.519 the in the non LTS. Right now, for example, nodes 886 00:51:16.840 --> 00:51:21.880 ESM support has finally completed, but it won't be available 887 00:51:22.000 --> 00:51:25.880 until what V twenty four without the flag, so I'll 888 00:51:25.960 --> 00:51:29.880 probably update to V twenty twenty. 889 00:51:33.639 --> 00:51:34.039 Twenty three. 890 00:51:34.760 --> 00:51:35.360 How are you sure? 891 00:51:35.480 --> 00:51:35.679 AJ? 892 00:51:37.599 --> 00:51:41.039 Now I have a very good news for you. I 893 00:51:41.159 --> 00:51:44.119 am really very good news. We are likely thinking of 894 00:51:44.239 --> 00:51:45.679 backparting it to twenty two. 895 00:51:46.320 --> 00:51:46.519 Yeah. 896 00:51:46.559 --> 00:51:50.639 Oh sweet, that's great. Yeah, that's that's that's amazing. Yeah, 897 00:51:50.639 --> 00:51:53.760 because that that's something I've not been using ESM because 898 00:51:53.960 --> 00:51:56.159 you know, like, why would I publish something to NPM 899 00:51:56.239 --> 00:51:59.440 that breaks everybody else's stuff and everybody else has to transpile, 900 00:51:59.559 --> 00:52:02.440 But then all those people using bundlers anyway, like you know, 901 00:52:02.719 --> 00:52:04.719 sm just didn't make any sense. And then when I 902 00:52:04.760 --> 00:52:07.559 saw that, I was like, yeah, finally I get to 903 00:52:08.199 --> 00:52:11.400 to not have to screw around with all this you know, 904 00:52:11.559 --> 00:52:12.559 window crap. 905 00:52:13.760 --> 00:52:15.639 This raises, this raises the good point. It's like why 906 00:52:15.679 --> 00:52:18.000 do we have this, you know, the schedule you know, 907 00:52:18.559 --> 00:52:22.559 back if you think back to when before node niogs, 908 00:52:22.840 --> 00:52:25.639 Node was originally going way too slow. I just came 909 00:52:25.679 --> 00:52:29.159 and was going way too fast. So the CELTS schedule 910 00:52:29.320 --> 00:52:31.360 was a you know, let's find a middle ground, like 911 00:52:31.440 --> 00:52:34.480 we're going to have one LTS per year, but why 912 00:52:34.559 --> 00:52:37.679 do two majors? And the reason for that is because 913 00:52:37.719 --> 00:52:40.440 the ecosystem needs to be able to have these features 914 00:52:40.519 --> 00:52:43.800 out at a faster rate than only one release per year. 915 00:52:45.000 --> 00:52:47.360 And so you know, the the the short term like 916 00:52:47.519 --> 00:52:53.000 odd numbered currents, those are primarily to help the developer 917 00:52:53.079 --> 00:52:57.599 ecosystem in Node, not the like enterprise you know, production users. 918 00:52:58.400 --> 00:53:01.440 Then it's there to help like the module developers and 919 00:53:01.480 --> 00:53:05.519 the ecosystem that are producing all of these dependencies keep 920 00:53:05.639 --> 00:53:08.159 up on a rate of change and allows Node to 921 00:53:08.280 --> 00:53:10.679 be you know, to know like what's actually being used? 922 00:53:10.719 --> 00:53:12.280 How does this need to be evolved? You know, you know, 923 00:53:12.440 --> 00:53:15.360 like actually get used to these things before it goes LTS, 924 00:53:15.480 --> 00:53:18.000 before it goes where we have to maintain something long term. 925 00:53:18.440 --> 00:53:20.880 And it's still considered to be a stable version, an 926 00:53:20.920 --> 00:53:24.519 official stable version, So I'm not like working on some 927 00:53:24.800 --> 00:53:28.159 beta or whatever. I am working on an official version. 928 00:53:28.199 --> 00:53:32.159 I just get the let's call it modern or bloody 929 00:53:32.360 --> 00:53:35.239 bleeding edge features sooner and I don't have to wait 930 00:53:35.320 --> 00:53:38.159 a full year, yes for that stuff, and I can 931 00:53:38.440 --> 00:53:40.840 have it ready in advance of that LTS release. 932 00:53:41.159 --> 00:53:44.559 It still respects semver, so you can expect that there 933 00:53:44.599 --> 00:53:49.800 shouldn't be really any breaking changes, but features going more quickly, 934 00:53:49.880 --> 00:53:52.079 and it really does help us in terms of like 935 00:53:52.559 --> 00:53:55.239 the versions we promote to LTS. It's great to have 936 00:53:55.440 --> 00:53:57.760 that six months as a current because that really helps 937 00:53:57.840 --> 00:54:00.559 us find out, like, are there an things that we 938 00:54:00.719 --> 00:54:02.800 missed in terms of like did something was it more 939 00:54:02.840 --> 00:54:05.840 breaking than we expected? And you know means sort of 940 00:54:05.880 --> 00:54:07.559 that six months means that by the time we go 941 00:54:07.639 --> 00:54:10.159 to LTS, we have a much better chance of it's 942 00:54:10.199 --> 00:54:12.840 just being worrying for everybody, which is what we like. 943 00:54:14.480 --> 00:54:17.000 I really want to be respectful of all your time. 944 00:54:17.400 --> 00:54:21.079 We are nearing the time usually where we start pushing 945 00:54:21.159 --> 00:54:25.480 towards picks. I'd love to continue this conversation for now. 946 00:54:25.559 --> 00:54:29.679 It's also easier earlier for me because we've switched to 947 00:54:29.800 --> 00:54:33.559 daylight savings, and you guys well off of daylight savings, 948 00:54:33.599 --> 00:54:35.719 and you guys are still, at least in the States, 949 00:54:35.760 --> 00:54:38.400 are still there. So I don't know how long you 950 00:54:38.519 --> 00:54:44.079 guys can go. Do we have another thirty something minutes 951 00:54:44.239 --> 00:54:46.400 or do we need to start thinking about wrapping up? 952 00:54:47.880 --> 00:54:48.400 I got time? 953 00:54:49.039 --> 00:54:51.360 Yeah, I'm okay, I'm okay. 954 00:54:51.639 --> 00:54:53.920 Okay, let's keep on going at least for a while. 955 00:54:54.000 --> 00:54:57.760 Let's see how far we can push it. Anything else 956 00:54:57.800 --> 00:55:00.400 about this pillar before we go to the next one, 957 00:55:00.440 --> 00:55:07.360 which is a whopper? Okay? Then, so pillar number four, 958 00:55:08.199 --> 00:55:14.159 it's automated testing, code review, and conformance as much as possible. Again, 959 00:55:14.559 --> 00:55:18.280 this is like an absolute truism of software development that 960 00:55:18.599 --> 00:55:21.480 has you know, it's true for note, but it's practically 961 00:55:21.559 --> 00:55:24.519 true everywhere else in the world. By the way, there's 962 00:55:24.599 --> 00:55:27.000 this click, so I don't know where it's coming from, 963 00:55:27.159 --> 00:55:31.280 but guys, please be aware that there's like this clicking 964 00:55:31.559 --> 00:55:38.440 sound going on anyway. So what do we have to 965 00:55:38.599 --> 00:55:43.719 say about automating tests and code reviews and conformance that's 966 00:55:44.079 --> 00:55:47.840 no specific or is it just you know do it? 967 00:55:48.800 --> 00:55:51.239 I think what my perspective on this would be is that, 968 00:55:51.880 --> 00:55:53.800 you know, one of the advantages white people we here 969 00:55:54.119 --> 00:55:56.719 use nogests is that they can move really quickly and 970 00:55:56.760 --> 00:56:01.000 they can innovate quickly. For me, that's great if you 971 00:56:01.039 --> 00:56:03.800 can move quickly, but it makes your testing and your 972 00:56:03.840 --> 00:56:06.440 regression tests all the more important. So while this is 973 00:56:06.960 --> 00:56:09.760 very important in most cases, it's even more important when 974 00:56:09.760 --> 00:56:13.199 you're moving fast, and because no lets you move fast, 975 00:56:13.880 --> 00:56:15.320 that's why it's so relevant to me. 976 00:56:18.360 --> 00:56:22.280 I'm totally I totally agree. Part of my job at 977 00:56:22.320 --> 00:56:26.320 almost everywhere that I've worked in the past over a 978 00:56:26.440 --> 00:56:31.480 decade is going into existing projects and starting to mess 979 00:56:31.519 --> 00:56:36.280 with them and literally break them. And like, the difference 980 00:56:36.360 --> 00:56:39.599 between between having tests and not having tests is like 981 00:56:39.960 --> 00:56:43.679 life and death. Literally, It's it's like, am I how 982 00:56:43.800 --> 00:56:46.519 confident do I feel even going into this project? 983 00:56:48.239 --> 00:56:48.440 Yeah? 984 00:56:48.519 --> 00:56:51.159 It's like if you can make if you can make 985 00:56:51.239 --> 00:56:54.760 a change, run the test suite and feel pretty comfortable 986 00:56:54.800 --> 00:56:56.679 that it's not going to the world's not gonna light on. 987 00:56:56.760 --> 00:56:59.519 Fire, that's what lets you move fast. 988 00:57:00.119 --> 00:57:01.480 Don't if you're like, oh, I made a. 989 00:57:01.559 --> 00:57:06.039 Change, but nothing's testing this. You're you're always very cautious, right, 990 00:57:06.159 --> 00:57:07.840 I think, and you're not going to go as fast. 991 00:57:09.400 --> 00:57:14.840 Now you did differentiate between like the three different kinds 992 00:57:14.840 --> 00:57:18.719 of tests that people usually talk about, which is unit tests, 993 00:57:19.239 --> 00:57:23.880 integration tests, and end to end tests. Now I'm curious, 994 00:57:24.599 --> 00:57:30.119 like because I hear people, different people putting different emphasis 995 00:57:30.280 --> 00:57:33.960 on different types of tests. So I hardly ever encounter 996 00:57:34.159 --> 00:57:37.400 people who say, you know, you don't need tests, But 997 00:57:37.559 --> 00:57:41.280 I do encounter people who say, you know, it's all 998 00:57:41.320 --> 00:57:44.440 about the end to end tests, and other people are saying, no, 999 00:57:44.719 --> 00:57:47.400 it's all about the unit tests and so forth. So 1000 00:57:47.519 --> 00:57:50.679 I am curious where you guys, which camp you guys 1001 00:57:50.760 --> 00:57:53.320 fall in, if you even do fall in a camp. 1002 00:57:55.519 --> 00:57:58.000 For me, I don't necessarily care about the type of test. 1003 00:57:58.119 --> 00:58:00.679 I care about the test coverage. And I know a 1004 00:58:00.719 --> 00:58:02.519 lot of people, you know, have a problem with chasing, 1005 00:58:02.960 --> 00:58:05.199 like you know, complete test coverage and stuff. 1006 00:58:05.840 --> 00:58:08.360 I don't measuring test coverage. 1007 00:58:08.480 --> 00:58:12.280 Right, I don't care necessarily what kind of test it is. 1008 00:58:12.920 --> 00:58:17.599 I care about is this line of code tested? And 1009 00:58:18.119 --> 00:58:21.239 too often, you know, you know, folks will only test 1010 00:58:21.320 --> 00:58:23.840 the happy path, you know, the only the right test 1011 00:58:23.920 --> 00:58:26.519 based on what they want the code to do, not 1012 00:58:26.920 --> 00:58:29.559 based on what the code actually does. Uh, and they 1013 00:58:29.639 --> 00:58:32.360 end up missing, like you know, coverage on half the 1014 00:58:32.679 --> 00:58:36.639 branches that their code, that their code takes or could take, 1015 00:58:36.679 --> 00:58:38.199 and then they get it into production or make some 1016 00:58:38.280 --> 00:58:40.199 kind of refactoring change and things just break. 1017 00:58:42.360 --> 00:58:45.800 My one of my problems with end two end tests, 1018 00:58:46.599 --> 00:58:50.119 which on the face of on the face of it, 1019 00:58:50.320 --> 00:58:53.760 and to end tests like like they have like they 1020 00:58:53.920 --> 00:58:56.960 could have been the best tests because they literally test 1021 00:58:57.039 --> 00:59:01.400 the system as it should work, but they're from my perspective, 1022 00:59:01.480 --> 00:59:04.320 there are two main issues with it. One is that 1023 00:59:04.719 --> 00:59:09.679 they can run pretty long, which means that people run 1024 00:59:09.760 --> 00:59:15.079 them less often. And the other problem is that testing 1025 00:59:15.199 --> 00:59:18.440 coverage with end to endests, or achieving good coverage with 1026 00:59:18.639 --> 00:59:21.280 end to end tests can be pretty challenging. 1027 00:59:23.119 --> 00:59:26.320 I think a lot of times, as I say, I 1028 00:59:26.360 --> 00:59:28.920 think I'd agree with kind of the challenges, like the 1029 00:59:30.039 --> 00:59:31.960 I think the end N tests like along with that 1030 00:59:32.159 --> 00:59:35.239 is it's sometimes harder to figure out what went wrong, 1031 00:59:36.280 --> 00:59:39.000 or like you made a tiny change and you only 1032 00:59:39.440 --> 00:59:41.360 if you only find that in your end end test, 1033 00:59:41.440 --> 00:59:43.400 it's probably going to be hard to figure out what 1034 00:59:43.519 --> 00:59:45.239 that tiny change is versus. 1035 00:59:45.119 --> 00:59:46.760 List you founders before production. 1036 00:59:47.039 --> 00:59:50.039 Yeah, no, no, So I think it's a balance between 1037 00:59:50.079 --> 00:59:52.360 the two, right, Like I think having unit tests, which 1038 00:59:52.400 --> 00:59:55.239 gives you really good coverage of the very specific things, 1039 00:59:55.480 --> 00:59:58.280 will help you find like, hey, I just made a 1040 00:59:58.320 --> 01:00:01.760 commit and I broke something like on the you know, 1041 01:00:02.719 --> 01:00:06.239 but worlsthing small. I can find that very easily. And 1042 01:00:06.360 --> 01:00:08.360 so you want you want as much unit testing as 1043 01:00:08.400 --> 01:00:10.679 you as you as you can afford to cover you know, 1044 01:00:10.760 --> 01:00:13.000 find those things. But then you still definitely need the 1045 01:00:13.119 --> 01:00:15.840 end to end tests. But you probably don't need to 1046 01:00:15.960 --> 01:00:18.880 test every single thing in the end t end test because, 1047 01:00:18.920 --> 01:00:22.840 like you said, that quickly becomes too long, and you 1048 01:00:22.920 --> 01:00:24.840 know you can't run it as often. Right, So it's 1049 01:00:24.880 --> 01:00:28.079 finding that right balance between you know, having your unit 1050 01:00:28.199 --> 01:00:29.880 tests that can fail, only they won't be able to 1051 01:00:29.920 --> 01:00:32.800 cover everything in the end to end style, but covering 1052 01:00:32.840 --> 01:00:34.519 as much as you can, and then as much of 1053 01:00:34.599 --> 01:00:36.880 the the end end testing is as practical so that 1054 01:00:36.960 --> 01:00:38.760 it still gets run on a regular basis. 1055 01:00:39.239 --> 01:00:41.920 Also, it's much closer to the actual code, so you're 1056 01:00:42.039 --> 01:00:45.760 much less likely to miss branches, at least at the unit. 1057 01:00:45.679 --> 01:00:49.159 Level, right, And a lot of times the integration tests 1058 01:00:50.239 --> 01:00:55.159 are incapable of testing particular branches, like particularly if their 1059 01:00:55.239 --> 01:00:58.559 edge cases or you know, should only happen in like 1060 01:00:58.639 --> 01:01:03.119 critical failure situation where you're into end test isn't actually 1061 01:01:03.159 --> 01:01:06.480 able to trigger those right because it's it's meant to 1062 01:01:06.519 --> 01:01:09.239 be some internal failure or IO is failing in some 1063 01:01:09.440 --> 01:01:13.760 case actually make it make likely. 1064 01:01:14.800 --> 01:01:18.239 Yeah, we all know the remedy to to a critical 1065 01:01:18.920 --> 01:01:20.960 problem which is consoler. 1066 01:01:22.440 --> 01:01:23.760 Mm hmmm, of course. 1067 01:01:24.119 --> 01:01:24.320 Yeah. 1068 01:01:26.800 --> 01:01:31.840 Okay, anything else we want to say about tests, any 1069 01:01:31.960 --> 01:01:35.960 recommendations about the systems you guys use for testing, Any 1070 01:01:36.039 --> 01:01:39.960 particular system or mechanism I should be using as a 1071 01:01:40.000 --> 01:01:41.119 node developer. 1072 01:01:42.079 --> 01:01:44.639 Use no tests, use the new test framework, builped into 1073 01:01:44.679 --> 01:01:45.159 the run time. 1074 01:01:46.400 --> 01:01:49.760 What I can tell is what not to use. Okay, 1075 01:01:51.199 --> 01:01:57.039 don't you just make yourself a faire No, this is true. 1076 01:01:57.119 --> 01:01:59.920 Okay, if you're building a node system, just as a 1077 01:02:00.039 --> 01:02:02.320 lot of good features. If you're building if you're using 1078 01:02:02.360 --> 01:02:07.239 it for some of the front and meta frameworks, okay, 1079 01:02:08.000 --> 01:02:11.039 But if you're building another app and EPI or something 1080 01:02:11.039 --> 01:02:15.440 like that, don't use it, I recommend because you cannot 1081 01:02:15.719 --> 01:02:18.679 test hundred percent of the branches with it, and therefore 1082 01:02:18.960 --> 01:02:23.119 it completely defeats the purpose of a testing framework. So 1083 01:02:24.639 --> 01:02:27.039 if I can't, why is that by the way, because 1084 01:02:27.079 --> 01:02:28.280 the monkey branches globals. 1085 01:02:28.480 --> 01:02:32.920 So if the no emits an error in one of 1086 01:02:33.000 --> 01:02:35.159 his own APIs in. 1087 01:02:36.719 --> 01:02:39.480 However, the error object is not create is different and 1088 01:02:39.559 --> 01:02:42.280 the one that just is put in the global. So 1089 01:02:42.480 --> 01:02:45.480 if you do error instance of error, it tron folds 1090 01:02:45.719 --> 01:02:46.840 even though it's an error. 1091 01:02:50.320 --> 01:02:50.960 You don't know. 1092 01:02:53.199 --> 01:02:57.440 Well, now we have the j aspective error is error. 1093 01:03:00.960 --> 01:03:03.719 I mean that that should that should help. But but yeah, 1094 01:03:03.760 --> 01:03:06.760 with with Justin in the fund, just Jesment, a couple others, 1095 01:03:06.920 --> 01:03:09.880 you know, had this issuable floor where the test and 1096 01:03:09.960 --> 01:03:12.559 it's get the test you write ends up testing the 1097 01:03:12.679 --> 01:03:16.719 mock rather than testing, you know, the actual run time 1098 01:03:16.800 --> 01:03:19.400 the actual code. We had this problem workers, you know 1099 01:03:19.480 --> 01:03:21.960 for the longest time. We're doing local tests, you know, 1100 01:03:22.599 --> 01:03:25.920 because our test framework originally, like that client side part, 1101 01:03:26.760 --> 01:03:28.920 the original version of many flour, was actually running a note. 1102 01:03:29.840 --> 01:03:32.519 So when you would go to all protecting your worker 1103 01:03:32.599 --> 01:03:35.159 and test it, you were actually testing it against nodes 1104 01:03:35.159 --> 01:03:38.119 implementation of something like readable stream. And then you actually 1105 01:03:38.119 --> 01:03:39.840 go to run at the runtime and oaks it breaks 1106 01:03:39.880 --> 01:03:42.280 because we have slight differences and you know, we're getting 1107 01:03:42.280 --> 01:03:43.840 away from that now where you can actually test them 1108 01:03:43.880 --> 01:03:47.239 the actual production code. But a lot of these testom 1109 01:03:47.280 --> 01:03:49.920 works like just have that fundamental problem where you're not 1110 01:03:50.199 --> 01:03:51.760 testing the thing you're actually running. 1111 01:03:54.440 --> 01:03:56.880 And I think Mitaylo's point might be like, it has 1112 01:03:56.960 --> 01:03:59.800 some advantages if you're you know, closer to the front 1113 01:03:59.880 --> 01:04:02.360 end side of things, but if you're really just a 1114 01:04:02.480 --> 01:04:05.679 node micro service, you might be better served by something 1115 01:04:05.760 --> 01:04:08.360 that's more no focused versus that. 1116 01:04:09.559 --> 01:04:12.480 And in that case, just use the built in node 1117 01:04:12.519 --> 01:04:22.320 testing framework. Yeah cool, Okay, moving on to the next one, 1118 01:04:22.519 --> 01:04:26.000 and I think you know what we'll see if this 1119 01:04:26.159 --> 01:04:27.960 is the last one, or we'll manage to get to 1120 01:04:28.119 --> 01:04:30.280 number six. It's kind of stopping in the middle. If 1121 01:04:30.719 --> 01:04:33.360 we stop in this one, and then we'll give us 1122 01:04:33.679 --> 01:04:36.360 an incentive to do another episode. I'd love to have 1123 01:04:36.519 --> 01:04:40.719 you guys on again. This is such an awesome conversation. Okay, 1124 01:04:40.840 --> 01:04:44.400 then number five and again, this is just a golden 1125 01:04:44.480 --> 01:04:48.280 rule in software development, but I think it has special 1126 01:04:48.400 --> 01:04:53.159 meaning in the context of node and that's avoid dependency creep. 1127 01:04:55.199 --> 01:04:58.719 Can we explain what dependency creep means in general and 1128 01:04:58.800 --> 01:05:05.320 what it means specif defically in NOE. So this is. 1129 01:05:07.119 --> 01:05:16.320 Probably one of the most misunderstood practice, especially lately. It's 1130 01:05:17.559 --> 01:05:20.840 like the node has been at the success it had 1131 01:05:21.679 --> 01:05:25.079 only because it was able to solve one specific problem. 1132 01:05:25.199 --> 01:05:28.440 In fact, NO didn't do it, and PM did it 1133 01:05:28.800 --> 01:05:33.000 found a way to do software reuse at massive scale. 1134 01:05:33.880 --> 01:05:38.280 Okay, and by by what ques mechanism? 1135 01:05:38.679 --> 01:05:43.079 Well, by allowing it turns out that your substantial portion 1136 01:05:43.239 --> 01:05:45.199 of that reuse pretty much. 1137 01:05:46.519 --> 01:05:47.880 I don't know if it's a good thing or a 1138 01:05:47.960 --> 01:05:51.239 bad thing, Okay, I am one of like I think. 1139 01:05:52.719 --> 01:05:55.440 I have that you're that guy from the x k 1140 01:05:55.639 --> 01:06:04.960 CD strip about that. It's sortaally it ye, yes, so. 1141 01:06:06.840 --> 01:06:07.920 The that's it. 1142 01:06:08.480 --> 01:06:14.000 Okay, So it's avoid dependency cree so not jes at 1143 01:06:14.079 --> 01:06:17.960 the massive success due to this software used. It allows 1144 01:06:18.079 --> 01:06:21.119 you to, for example, use different versions of the same 1145 01:06:21.199 --> 01:06:25.400 libraries in different dependency trees of your app. 1146 01:06:25.719 --> 01:06:26.000 Okay. 1147 01:06:26.440 --> 01:06:29.679 This means that you can have and this happens very often, 1148 01:06:30.000 --> 01:06:32.880 readable stream one in your code based, retable stream two 1149 01:06:33.079 --> 01:06:35.719 in your code based litable Steam three in your code base, 1150 01:06:35.760 --> 01:06:36.840 and readable steam four. 1151 01:06:37.559 --> 01:06:40.559 Okay, and when I will ship five, you likely have five. 1152 01:06:40.639 --> 01:06:45.840 We'll have five. Okay. That's what it is. 1153 01:06:46.119 --> 01:06:50.719 Okay, so there is there are some modules that get 1154 01:06:50.760 --> 01:06:54.159 a lot of that are and a lot of dependency 1155 01:06:54.280 --> 01:07:00.280 change because typically for the typically historic reason and at 1156 01:07:00.320 --> 01:07:04.239 that point in time it's they were useful, but now 1157 01:07:04.519 --> 01:07:08.719 probably way less. So so maybe you should stop using 1158 01:07:08.840 --> 01:07:13.239 readable that stream and maybe start using you know, not 1159 01:07:13.760 --> 01:07:15.880 they're not just an austream module. 1160 01:07:15.639 --> 01:07:19.360 Because that's all of it. But however there's a lot 1161 01:07:19.440 --> 01:07:21.320 of things where you still want to use that module. 1162 01:07:21.440 --> 01:07:24.559 And therefore here we are. Okay, so you. 1163 01:07:24.679 --> 01:07:28.039 Made actually two points here. I think first of all, 1164 01:07:28.159 --> 01:07:34.760 you're saying node itself is advancing and it's offering many 1165 01:07:34.880 --> 01:07:37.559 built in features that in the past did not exist 1166 01:07:37.760 --> 01:07:40.519 that in the past we would have needed to bring in, 1167 01:07:41.079 --> 01:07:45.199 like third party libraries. Now they're building features in the platform. 1168 01:07:45.800 --> 01:07:50.519 And as with the browser, whenever I can leverage an 1169 01:07:50.559 --> 01:07:54.119 existing part of the platform rather than bringing in a dependency, 1170 01:07:54.800 --> 01:07:58.000 it's it's almost always a good idea. It's going to 1171 01:07:58.079 --> 01:08:02.440 be a stable API or well tested service. API is 1172 01:08:02.519 --> 01:08:04.760 going to be there forever, I don't need to worry 1173 01:08:04.800 --> 01:08:09.480 about maintainability, about security, about who gets ownership of it 1174 01:08:09.639 --> 01:08:14.880 and starts pushing malware into it or whatever. And it's 1175 01:08:15.000 --> 01:08:18.880 probably going to perform better and so many advantages. So 1176 01:08:19.199 --> 01:08:24.159 that's an obvious thing. But the other point you're saying 1177 01:08:24.319 --> 01:08:30.119 is that I should be wary of having multiple versions 1178 01:08:30.439 --> 01:08:36.880 of the same package running within my single node instance. 1179 01:08:37.079 --> 01:08:39.560 Now I understand why it's a bad thing on the 1180 01:08:39.640 --> 01:08:44.920 browser side, because I've actually seen a browser based application 1181 01:08:45.159 --> 01:08:50.199 deliver three different versions of moment js which resulted in 1182 01:08:50.439 --> 01:08:53.439 like a huge download, which is a problem on the client. 1183 01:08:54.359 --> 01:08:56.439 Why is it a problem in my node server? 1184 01:08:56.560 --> 01:09:03.439 Though, the first problem is related to your surface attack. 1185 01:09:04.399 --> 01:09:07.119 Okay, the more dependency you have, the more you are 1186 01:09:07.199 --> 01:09:12.199 exposed to potential attack. You want to have genetically dependency 1187 01:09:12.239 --> 01:09:14.720 that you need and only the dependency that. 1188 01:09:14.760 --> 01:09:16.800 You need in your tree. Okay. 1189 01:09:17.640 --> 01:09:20.800 So this is the first point okay, which you know 1190 01:09:21.000 --> 01:09:23.399 each one is a vector, is a potential attack factor, 1191 01:09:23.560 --> 01:09:26.319 so you need to treat them like that, okay. And 1192 01:09:26.800 --> 01:09:31.159 the other stuff is it increases significantly the install time 1193 01:09:32.039 --> 01:09:34.840 of the application. So if you do and increases I 1194 01:09:34.880 --> 01:09:38.800 don't know, see I time, okay, just attending bit Okay, 1195 01:09:39.159 --> 01:09:42.880 but then another app can have easily three four thousand 1196 01:09:42.920 --> 01:09:46.760 dependencies once all of a sudden done. And then you 1197 01:09:46.880 --> 01:09:49.920 start saying, oh, Okay, can I just maybe remove a 1198 01:09:50.000 --> 01:09:50.880 thousand of those? 1199 01:09:51.560 --> 01:09:55.159 Okay? Each one of them needs to be downloaded independence, 1200 01:09:56.880 --> 01:09:59.760 you know, I'm just like a lot of them, like 1201 01:10:00.439 --> 01:10:05.319 some of them that are trivia, okay, and frankly they should, 1202 01:10:06.000 --> 01:10:09.960 you know, not be molelized, but there we are. And 1203 01:10:10.079 --> 01:10:11.840 some of them they need to. 1204 01:10:11.840 --> 01:10:14.800 Be down leveled, right, I mean, they just people just 1205 01:10:14.880 --> 01:10:17.840 don't update their dependencies when they can, and so some 1206 01:10:18.000 --> 01:10:21.800 of them end up just being brought in just because 1207 01:10:21.840 --> 01:10:23.920 somebody decided not to update. 1208 01:10:25.199 --> 01:10:28.840 It's it's also the fact that it's like it's like 1209 01:10:29.239 --> 01:10:31.600 like this sort of a skeleton, like the hip bone, 1210 01:10:31.680 --> 01:10:34.039 like how that song go the hip bones connected to 1211 01:10:34.159 --> 01:10:36.560 the high bone and so forth. So you bring in 1212 01:10:36.680 --> 01:10:39.520 one note package and that brings in two more, which 1213 01:10:39.640 --> 01:10:42.960 bring in eight more, which bring in sixteen more, and 1214 01:10:43.479 --> 01:10:45.680 and all of a sudden you have like the entire 1215 01:10:45.880 --> 01:10:51.239 universe downloaded into your node instance. And you did put 1216 01:10:51.319 --> 01:10:55.159 that comic strip in your article about how the NPM 1217 01:10:55.319 --> 01:10:59.840 modules folder is heavier than a black hole. How how 1218 01:11:00.399 --> 01:11:01.520 how do I contend with that? 1219 01:11:01.840 --> 01:11:05.760 You know, I think the principle was about, like be 1220 01:11:05.920 --> 01:11:08.880 more intentional about that. If you're gonna you can easily 1221 01:11:09.000 --> 01:11:12.600 pull in a package and you're using some small part 1222 01:11:12.640 --> 01:11:16.560 of that package, and but take you should take a 1223 01:11:16.640 --> 01:11:18.720 look at like, what all did that pull in? If 1224 01:11:18.760 --> 01:11:22.560 that pulled in one hundred other packages and you've effectively 1225 01:11:22.680 --> 01:11:25.560 replaced ten lines of code that you might have written yourself, 1226 01:11:25.760 --> 01:11:27.920 maybe you should just put the ten lines of code 1227 01:11:27.960 --> 01:11:32.039 in right, so you know, as Matteo said, the reuse 1228 01:11:32.159 --> 01:11:36.159 is one of the fast fantastic things about the ecosystem. 1229 01:11:36.199 --> 01:11:39.119 It's really easy to pull in code and reuse it. 1230 01:11:39.239 --> 01:11:42.079 That's great, But I think we could use a little 1231 01:11:42.119 --> 01:11:44.039 bit of a shift towards being a little bit more 1232 01:11:44.119 --> 01:11:46.720 intentional and looking at what you're pulling in versus the 1233 01:11:46.800 --> 01:11:50.239 benefit you get, so that you're you're sort of doing 1234 01:11:50.279 --> 01:11:53.760 the right balance between hey, I'm reusing code easily versus 1235 01:11:53.920 --> 01:11:56.000 the sort of risk that I'm taking on because you know, 1236 01:11:56.039 --> 01:11:58.439 I've got a huge amount of code. It's not just 1237 01:11:58.520 --> 01:12:00.159 the attack factor. What if there's a bug do you 1238 01:12:00.239 --> 01:12:04.039 want to have fixed? You know, are you able to 1239 01:12:04.119 --> 01:12:07.319 do that yourself? If not, that's something you should probably 1240 01:12:07.359 --> 01:12:08.319 at least think a little. 1241 01:12:08.159 --> 01:12:08.560 Bit about it. 1242 01:12:09.119 --> 01:12:14.239 Yeah, maybe you don't actually need left pad right, like, yeah, 1243 01:12:14.840 --> 01:12:21.399 you know, yeah, The sad thing is that, given the 1244 01:12:21.720 --> 01:12:26.000 average experience of developers, there's a good chance that half 1245 01:12:26.079 --> 01:12:28.720 our listeners don't even get that joke about left pad 1246 01:12:28.760 --> 01:12:32.800 because they came into the industry after it happened. Yeah. 1247 01:12:33.439 --> 01:12:35.640 Well, the question is are they still using it today. 1248 01:12:36.640 --> 01:12:38.600 There's a good chance that they are, though, but they 1249 01:12:38.680 --> 01:12:41.359 probably don't know it because they're probably you not using 1250 01:12:41.439 --> 01:12:44.560 it directly, they're probably using something that uses something which 1251 01:12:44.640 --> 01:12:45.359 uses left pad. 1252 01:12:46.399 --> 01:12:48.840 I think we need an ethos change to be more 1253 01:12:48.960 --> 01:12:52.880 like Go and Zig and other same languages, make the 1254 01:12:52.960 --> 01:12:56.760 standard library great again, and get rid of all the 1255 01:12:56.840 --> 01:13:00.520 crap dependencies that I mean, there's so much many even 1256 01:13:00.680 --> 01:13:04.920 security dependencies where the people who are doing it obviously 1257 01:13:05.079 --> 01:13:07.359 don't know what they're doing. You can't blame them because 1258 01:13:07.439 --> 01:13:09.479 no one who did know what they were doing was 1259 01:13:09.560 --> 01:13:12.359 doing it right. But I remember one of the early, 1260 01:13:13.520 --> 01:13:19.960 very very popular OTP libraries was atrocious. You know, there's 1261 01:13:20.119 --> 01:13:23.600 there's there in our industry, I think because of there 1262 01:13:23.680 --> 01:13:26.720 being so much money available, and thank goodness, there isn't now. 1263 01:13:26.800 --> 01:13:31.079 I actually think I hope that the interest rates stay high. 1264 01:13:31.119 --> 01:13:33.359 I hope they don't go down for the sake of 1265 01:13:33.399 --> 01:13:35.680 our industry for the sake of you know, lots of 1266 01:13:35.720 --> 01:13:38.600 other things. Maybe I don't know, but our industry was 1267 01:13:38.760 --> 01:13:42.680 ruined by low interest rates because with free money, there 1268 01:13:42.800 --> 01:13:46.439 was no responsibility to a customer, and then there was 1269 01:13:46.560 --> 01:13:51.600 no there was no craftsmanship, and and then it became 1270 01:13:52.159 --> 01:13:55.319 it became an ego thing like, look, I don't know 1271 01:13:55.439 --> 01:13:58.159 what I'm doing, and I'm getting so much done anyway. Look, 1272 01:13:58.199 --> 01:14:01.159 I don't understand how this frame work works. I don't 1273 01:14:01.279 --> 01:14:03.800 understand how the library works. But look how great I 1274 01:14:03.920 --> 01:14:06.720 am anyway, and we need some sort of an ethos 1275 01:14:06.800 --> 01:14:10.199 change to like, Hey, I'm able to do this with 1276 01:14:10.479 --> 01:14:13.680 just the standard library. Isn't that pretty cool? Hey I'm 1277 01:14:13.720 --> 01:14:16.800 able to understand how my code works. Hey I've got 1278 01:14:16.880 --> 01:14:19.800 a handle on what my application is doing. Because if 1279 01:14:19.840 --> 01:14:22.399 we don't have that etho shift, then we're we're gonna 1280 01:14:22.439 --> 01:14:24.319 get stuck in this the same rut that we're in. 1281 01:14:24.560 --> 01:14:25.800 I mean, like we're not going to leave the right 1282 01:14:25.800 --> 01:14:27.119 We're already stuck in the run. We're not going to 1283 01:14:27.199 --> 01:14:27.560 get out of it. 1284 01:14:29.560 --> 01:14:31.840 So an interesting thing that I have to mention. So 1285 01:14:31.920 --> 01:14:35.159 a few episodes back, we've had we had Ryan Doll 1286 01:14:35.239 --> 01:14:37.760 as a guest to talk about dn O two when 1287 01:14:37.840 --> 01:14:41.560 it came out. Now, interestingly, when DNO itself first came 1288 01:14:41.600 --> 01:14:44.880 out dn O one, one of the things about it 1289 01:14:45.199 --> 01:14:49.720 was that they avoided NPM and did try to provide 1290 01:14:49.880 --> 01:14:53.560 like their own more significant built in standard library. And 1291 01:14:53.720 --> 01:14:57.640 the thing about DNO two is that they will, surprise, surprise, 1292 01:14:57.680 --> 01:14:59.880 they now support NPM because it turns out that we 1293 01:15:00.000 --> 01:15:02.399 without supporting NPM, you can't really. 1294 01:15:03.399 --> 01:15:04.399 Get enough investment. 1295 01:15:05.039 --> 01:15:08.079 Well, not that you can't really build practical things, especially 1296 01:15:08.159 --> 01:15:10.239 for the enterprise users. 1297 01:15:10.720 --> 01:15:13.880 You just want to use users want to reuse NPM models. 1298 01:15:14.479 --> 01:15:16.399 I mean, that's all it is. So that that that 1299 01:15:16.560 --> 01:15:19.479 that the whole joke about NPM being as black hole, 1300 01:15:19.920 --> 01:15:23.159 that's exactly it. It's got such a massive gravity in 1301 01:15:23.199 --> 01:15:26.800 the ecosystem that you cannot avoid it, right and right. 1302 01:15:26.760 --> 01:15:29.439 But I don't I don't say I'm not going to 1303 01:15:29.479 --> 01:15:32.159 go use go because I don't have NPM, or I'm 1304 01:15:32.199 --> 01:15:34.880 not going to use Rust because I don't have NPM. Right. 1305 01:15:35.399 --> 01:15:37.560 I mean, when you create something new, when you create 1306 01:15:37.640 --> 01:15:40.720 something that's fundamentally different, you have the liberty to not 1307 01:15:41.039 --> 01:15:44.720 take the baggage you know from from prior years, Like 1308 01:15:44.840 --> 01:15:47.800 you don't you don't use C and and well, in 1309 01:15:47.920 --> 01:15:50.119 some rare cases you use see and go like seq 1310 01:15:50.239 --> 01:15:52.840 light or something like that. But you know, in other languages, 1311 01:15:52.920 --> 01:15:55.640 they're not They're not afraid to say, Hey, one of 1312 01:15:55.680 --> 01:15:57.640 the reasons we're creating a new language and a new 1313 01:15:57.720 --> 01:16:00.680 platform is because we want to leave the crap. We 1314 01:16:00.800 --> 01:16:02.720 don't want the craft to come with us. I'm not 1315 01:16:02.840 --> 01:16:05.159 I'm sad that Dino conceded on that point. 1316 01:16:05.640 --> 01:16:10.960 I'm not convinced the other languages have have totally I've 1317 01:16:11.039 --> 01:16:13.479 necessarily necessarily done better. They may be in at a 1318 01:16:13.520 --> 01:16:15.439 different point on their journey, Like I know and Go. 1319 01:16:15.720 --> 01:16:19.039 I'm I'm working on build packs for no jest. They're 1320 01:16:19.039 --> 01:16:21.920 written and go. That's the place we actually have like 1321 01:16:22.000 --> 01:16:25.680 a dependencies that's deleted, that's preventing things from being updated. 1322 01:16:25.760 --> 01:16:28.640 And so, like you know, NPM has gone through a 1323 01:16:28.760 --> 01:16:32.159 fairly long learning process, and some of these other languages, 1324 01:16:32.279 --> 01:16:35.520 like it'll be interesting to see if they end up 1325 01:16:35.680 --> 01:16:38.720 in the same place, or you know, they just haven't 1326 01:16:38.800 --> 01:16:40.880 hit some of the challenges that you get with the scale. 1327 01:16:40.960 --> 01:16:41.880 That note has gotten to you. 1328 01:16:42.479 --> 01:16:44.640 I'm trying to remember who said it. It might have 1329 01:16:44.720 --> 01:16:48.039 been Con't. I don't remember, but basically they said that 1330 01:16:48.199 --> 01:16:53.000 without NPM, we wouldn't have had carbon. So so even 1331 01:16:53.239 --> 01:16:58.680 even though even though NPM is not perfect, it's the 1332 01:16:58.800 --> 01:17:01.840 most used and that definitely says something. 1333 01:17:04.119 --> 01:17:09.640 Yes, yeah, I am said that they based Cargo around 1334 01:17:09.720 --> 01:17:11.600 n PM because it shows and it's got a lot 1335 01:17:11.640 --> 01:17:15.000 of the same problems, whereas the Go Package Manager is 1336 01:17:15.199 --> 01:17:18.279 empirically as perfect as it can be, meaning that it 1337 01:17:18.439 --> 01:17:21.239 has the fewest trade offs and you can prove that 1338 01:17:21.359 --> 01:17:24.439 mathematically looking at the graphs, and there's attack where that's 1339 01:17:24.520 --> 01:17:26.840 been done, so that that is really sad that we 1340 01:17:26.920 --> 01:17:30.279 actually have something that we know both mathematically and practically 1341 01:17:30.319 --> 01:17:32.079 works out and we still choose other things. 1342 01:17:33.000 --> 01:17:35.880 Well, there was not there, like they go back. 1343 01:17:36.720 --> 01:17:39.159 M I know, yeah, for NPM, I know, but I'm 1344 01:17:39.199 --> 01:17:41.319 saying cargo, but like it's it's sad. 1345 01:17:41.880 --> 01:17:43.840 Was not there, Sorry, it was not there. I think 1346 01:17:43.880 --> 01:17:45.439 it's Cargo pre dates the Go back. 1347 01:17:47.720 --> 01:17:48.159 Yeah. Yeah. 1348 01:17:48.960 --> 01:17:53.000 I came out very very very late in the game, 1349 01:17:53.560 --> 01:17:57.439 and for a long time, Go was in fact the 1350 01:17:57.560 --> 01:17:59.000 original Lino one. 1351 01:18:00.760 --> 01:18:03.479 Package package Management. 1352 01:18:03.960 --> 01:18:07.279 We came out from Dino from GO and they just said, 1353 01:18:07.319 --> 01:18:10.159 well you point us, do you point it to a URL? 1354 01:18:10.399 --> 01:18:13.159 And then it downloaded and they it handled it. 1355 01:18:13.439 --> 01:18:17.279 It handled it, okay, which was essentially our dependency we're 1356 01:18:17.359 --> 01:18:19.479 managing go prior to that. 1357 01:18:20.880 --> 01:18:23.800 Okay, yeah yeah yeah for the model repost, yeah, that 1358 01:18:24.319 --> 01:18:26.520 was definitely yeah, Okay, I see what you said. Yeah, 1359 01:18:26.520 --> 01:18:28.960 because the it came out in twenty eighteen and then 1360 01:18:29.000 --> 01:18:31.760 it was and it was confirmed final in twenty nineteen, 1361 01:18:31.840 --> 01:18:35.880 which it seems that's more recent than what it seems like. 1362 01:18:35.960 --> 01:18:37.880 It seems like it was a longer time ago. But 1363 01:18:37.920 --> 01:18:41.520 then I guess Rust wasn't really even hitting popularity until 1364 01:18:41.560 --> 01:18:44.439 after twenty eighteen. So when I think about it, I 1365 01:18:45.000 --> 01:18:47.760 my memory is wrong, My memory is corrupt. I'm faulty. 1366 01:18:48.279 --> 01:18:48.640 My bad. 1367 01:18:52.119 --> 01:18:54.000 Yeah, I mean is going back to something, you know, 1368 01:18:54.199 --> 01:18:56.840 the kind of the original thing with the tendency creep 1369 01:18:56.920 --> 01:18:59.199 and everything else. So NPM, like I said, it has 1370 01:18:59.239 --> 01:19:01.920 this massive grab and if if you know, folks are 1371 01:19:02.039 --> 01:19:04.119 using those modules, they want to keep they want to 1372 01:19:04.199 --> 01:19:07.079 keep using them. Unfortunately, there's just so many modules on 1373 01:19:07.079 --> 01:19:11.319 them they don't need to use. My canonical example, if 1374 01:19:11.319 --> 01:19:12.640 you go out there, and I don't want to like 1375 01:19:12.720 --> 01:19:14.560 pick on it too much, but there's a module out 1376 01:19:14.600 --> 01:19:16.479 there called is even all it. 1377 01:19:16.520 --> 01:19:18.720 Does that's parody, that's a joke. 1378 01:19:19.800 --> 01:19:22.439 It doesn't matter. I've seen people use it. It doesn't 1379 01:19:22.479 --> 01:19:24.680 matter if it's a joke because people I've actually seen 1380 01:19:24.760 --> 01:19:26.600 people use this in their code. 1381 01:19:27.760 --> 01:19:32.319 Because not a joke. They used it as not a joke, yes, 1382 01:19:32.520 --> 01:19:36.840 because it was that's story. 1383 01:19:37.600 --> 01:19:40.600 It is scary. But I I know, my the first 1384 01:19:40.640 --> 01:19:43.800 time I I found that isn't even module, which all 1385 01:19:43.880 --> 01:19:47.720 it does is is pull in is odd module and 1386 01:19:48.279 --> 01:19:48.680 negate it. 1387 01:19:50.239 --> 01:19:53.479 And that has a list of a million numbers, right 1388 01:19:53.800 --> 01:19:56.439 or something like that. It's it's not even something simple 1389 01:19:56.520 --> 01:19:58.239 like doing mod no, because I know one of the 1390 01:19:58.319 --> 01:20:02.279 parody modules just has a list of numbers like one 1391 01:20:02.359 --> 01:20:06.439 to a million, and then for every other one returns true. Okay, 1392 01:20:06.840 --> 01:20:07.720 so it's not that bad. 1393 01:20:08.239 --> 01:20:11.079 Now this actually does work, you know, and we'll check 1394 01:20:11.159 --> 01:20:13.520 to the validate that the input is a number and 1395 01:20:14.319 --> 01:20:16.319 you know, and that kind of thing that is odd. 1396 01:20:16.560 --> 01:20:19.399 But all is even does is pull that in and negated. 1397 01:20:19.920 --> 01:20:22.159 I've seen you know, there are a ton of moneys 1398 01:20:22.239 --> 01:20:26.880 on NPM that like you just don't need, and people 1399 01:20:27.039 --> 01:20:29.880 pull them in anyway because they're not thinking about it. 1400 01:20:29.920 --> 01:20:32.239 They're not being intentional about it. Going back to Michael's 1401 01:20:32.239 --> 01:20:35.359 ear their point or they don't understand what the model 1402 01:20:35.439 --> 01:20:38.800 is actually doing, right, and that's what they need to 1403 01:20:38.880 --> 01:20:41.720 be focusing on. Goes back to the same thing with 1404 01:20:41.800 --> 01:20:44.880 it we have a problem intentional about what you're doing. 1405 01:20:45.439 --> 01:20:47.760 I have a problem with that statement because, to a 1406 01:20:47.840 --> 01:20:52.520 great extent, the whole idea if of reuse is that 1407 01:20:52.760 --> 01:20:56.920 I don't need to think about the implementation details. I 1408 01:20:57.039 --> 01:21:00.359 can basically just look at the API surface and be 1409 01:21:00.520 --> 01:21:04.960 content with that. If I assume, if I can assume 1410 01:21:06.880 --> 01:21:13.680 let's call it a good a good actor, if I'm starting, 1411 01:21:13.840 --> 01:21:16.439 if I if I need to start looking under the 1412 01:21:16.520 --> 01:21:21.760 hood of every n PM module that I'm using, why 1413 01:21:21.880 --> 01:21:23.600 am I even using these modules? 1414 01:21:25.680 --> 01:21:28.159 It comes back to the you know, being intentional about 1415 01:21:28.159 --> 01:21:31.039 it right to some extent, Yeah, but you have to 1416 01:21:31.119 --> 01:21:34.119 understand as a trade off, if you don't understand what 1417 01:21:34.199 --> 01:21:37.119 the module is doing, it might be doing something incredibly 1418 01:21:37.399 --> 01:21:41.560 you know performance, you know costly, and you and sudden 1419 01:21:41.600 --> 01:21:43.760 your application is slowing down. You go into production. Why 1420 01:21:43.880 --> 01:21:46.039 is it slowing down? Well, you know, Michael and I 1421 01:21:46.600 --> 01:21:52.000 countless countless of consulting uh jobs. We went out and 1422 01:21:52.039 --> 01:21:54.800 found Hey, it's your dependencies that are slowing you down 1423 01:21:55.079 --> 01:21:57.920 because they're just not you know, written to be very 1424 01:21:58.520 --> 01:22:01.520 performing in any way. In prose ball, we didn't know that. 1425 01:22:01.640 --> 01:22:03.880 If we had known that, we wouldn't have used it. Well, 1426 01:22:04.439 --> 01:22:07.079 you know, do some digging, you know, look at what 1427 01:22:07.159 --> 01:22:12.560 your dependencies are doing, you know it. You have to 1428 01:22:12.640 --> 01:22:13.239 be aware of. 1429 01:22:13.319 --> 01:22:17.960 The a good metric because I think that with rails 1430 01:22:18.279 --> 01:22:20.520 and I don't think that this necessarily was what the 1431 01:22:20.640 --> 01:22:25.840 Rails community intended, but it bad pun you know, the 1432 01:22:25.960 --> 01:22:30.600 idea went off the rails uh dry right, don't repeat 1433 01:22:30.600 --> 01:22:33.760 yourself became it became a sacred cow that people didn't 1434 01:22:33.880 --> 01:22:37.760 understand and they just started to say it without knowing 1435 01:22:37.840 --> 01:22:39.960 what they were saying or what it was supposed to mean. 1436 01:22:40.800 --> 01:22:43.680 And this don't repeat yourself became this you know this 1437 01:22:44.560 --> 01:22:52.079 this religious uh month fervor. And I think a good 1438 01:22:52.119 --> 01:22:55.600 metric would be what does the number of letters you 1439 01:22:55.760 --> 01:22:58.920 have to type to search for it or or or 1440 01:22:59.079 --> 01:23:02.520 query for it exceed the number of characters you would 1441 01:23:02.560 --> 01:23:05.359 have to type in order to implement it. Because if so, 1442 01:23:06.399 --> 01:23:08.600 you're on the wrong track. You should just copy and 1443 01:23:08.680 --> 01:23:10.560 paste that code or type it out again. 1444 01:23:11.159 --> 01:23:16.159 It'll be interesting to see if AI code generators make 1445 01:23:16.199 --> 01:23:19.319 a dent in this if people can instead of pulling, 1446 01:23:19.399 --> 01:23:23.720 and if they actually make an improvement. Also, if somebody, 1447 01:23:23.840 --> 01:23:27.720 instead of pulling in a module that does something, can 1448 01:23:27.880 --> 01:23:32.319 stell like chat, GPT or copilot or whatever, right me 1449 01:23:32.479 --> 01:23:35.079 code that does that thing and then copy pastes it 1450 01:23:36.039 --> 01:23:38.439 into their code, is that better or worse? 1451 01:23:40.039 --> 01:23:43.600 I have had great success with chat GPT, writing far 1452 01:23:43.800 --> 01:23:47.119 better code than what exists in the ecosystem that I 1453 01:23:47.159 --> 01:23:49.479 could find. And I'm not just looking at modules that 1454 01:23:49.600 --> 01:23:52.359 have the fifteen hundred plus stars. I'll look for things 1455 01:23:52.439 --> 01:23:55.560 that have ten or no stars. I'm just looking for 1456 01:23:55.640 --> 01:23:57.560 the best code that's available, and I'll go peek at 1457 01:23:57.560 --> 01:24:00.720 the source code. Two things that come to mind. One 1458 01:24:01.039 --> 01:24:05.000 was Shot two fifty six, because web crypto has Shot 1459 01:24:05.079 --> 01:24:08.000 two fifty six, but it's really really slow because of 1460 01:24:08.039 --> 01:24:11.439 the context switches and the async. So if you need 1461 01:24:11.520 --> 01:24:14.000 Shot two fifty six for anything more than a one off, 1462 01:24:14.399 --> 01:24:17.079 I would not recommend using web Crypto. So all these 1463 01:24:17.159 --> 01:24:20.079 modules on NPM that have Shot two fifty six, they're 1464 01:24:20.119 --> 01:24:22.680 all really legacy there. You know, some of them are 1465 01:24:22.800 --> 01:24:26.560 using a transpiled buffer implementation from node like. None of 1466 01:24:26.600 --> 01:24:30.840 them are using unaight array and modern JavaScript. They're all 1467 01:24:30.960 --> 01:24:34.720 like decrepitly old. And I asked GPT to write me 1468 01:24:34.960 --> 01:24:38.560 from scratch a shot two fifty six, and I was 1469 01:24:38.720 --> 01:24:41.720 so skeptical. I spent two hours testing it, pulling from 1470 01:24:41.800 --> 01:24:44.880 other libraries, like grabbing their tests and bringing that in 1471 01:24:45.199 --> 01:24:47.600 because I thought there's no way it that it created 1472 01:24:47.640 --> 01:24:51.319 a better library than anything that exists on NPM in 1473 01:24:51.680 --> 01:24:54.680 a one shot. But it is a really well known algorithm. 1474 01:24:54.720 --> 01:24:57.279 There's lots of training data and lots of languages, and 1475 01:24:57.479 --> 01:25:00.439 GPT does kind of tend towards simplicity. It doesn't have 1476 01:25:00.520 --> 01:25:03.840 a context window to be able to create seven different 1477 01:25:03.880 --> 01:25:06.640 class hierarchies. To do something, it kind of has to 1478 01:25:06.720 --> 01:25:08.359 be able to do it in a function or two, 1479 01:25:08.800 --> 01:25:11.880 which I think you know also speaks to the greater 1480 01:25:12.039 --> 01:25:15.880 average of the human consciousness. Humans are not really good 1481 01:25:15.920 --> 01:25:20.039 at holding seven different class hierarchies in their context windows, 1482 01:25:20.079 --> 01:25:22.079 although they like to think that they do. But in 1483 01:25:22.199 --> 01:25:26.079 some ways I think that GPT is more truthfully reflecting 1484 01:25:26.159 --> 01:25:30.439 reality than people are perceiving it. Another instance was a 1485 01:25:30.520 --> 01:25:33.880 seaboar parser, and you know, seaboar is something there's not 1486 01:25:34.199 --> 01:25:39.199 very many implementations of it. But the implementations that exist 1487 01:25:40.119 --> 01:25:43.439 outside of JavaScript are extremely high quality, and so it 1488 01:25:43.600 --> 01:25:46.479 was able to write me a seaboard partser in a 1489 01:25:46.560 --> 01:25:49.119 one shot. Other than I had to make a follow 1490 01:25:49.239 --> 01:25:52.199 up prompt because there was one function that didn't fit 1491 01:25:52.279 --> 01:25:54.680 in it. I guess didn't fit in its context window. 1492 01:25:54.960 --> 01:25:56.680 So I had this. I could tell that it didn't 1493 01:25:56.720 --> 01:25:59.399 have one of the functions was missing, and so I said, hey, 1494 01:25:59.520 --> 01:26:01.800 you're missing this, and I took that and it worked. 1495 01:26:02.399 --> 01:26:07.199 And so it's at least in JavaScript, I can tell that. 1496 01:26:07.359 --> 01:26:08.720 And and part of it has to do with my 1497 01:26:08.880 --> 01:26:11.960 memories because in GPT, I've told it, hey, remember that 1498 01:26:12.119 --> 01:26:15.039 I prefer this style. Remember that I prefer this style. 1499 01:26:15.119 --> 01:26:18.840 So I have also prompted it to be simpler in 1500 01:26:18.920 --> 01:26:20.880 the way that it writes code. But it was able 1501 01:26:20.920 --> 01:26:25.560 to one shot two complex things that you know, certainly 1502 01:26:25.600 --> 01:26:28.680 nobody could write in thirty seconds, and very few people 1503 01:26:28.720 --> 01:26:31.319 could write and feel confident that they wrote it correctly. 1504 01:26:32.199 --> 01:26:33.920 And you know, I was able to test it and 1505 01:26:34.000 --> 01:26:36.600 see that it did work. So but I think it 1506 01:26:36.720 --> 01:26:39.479 takes the senior mindset to do that in the first place, 1507 01:26:39.520 --> 01:26:42.000 because you have to be looking for Hey, I looked 1508 01:26:42.000 --> 01:26:44.520 at the code of this shot twoty six implementation on NPM, 1509 01:26:44.760 --> 01:26:48.079 and it's absolute garbage. Not necessarily because it was always garbage, 1510 01:26:48.760 --> 01:26:52.760 but sometimes just because like it's got browser of fied transportations, 1511 01:26:52.760 --> 01:26:56.520 which hey, back in you know, two thousand and ten, 1512 01:26:56.680 --> 01:26:59.439 that's that that was what you had to do. 1513 01:26:59.720 --> 01:27:02.399 That was I don't think it's the senior mindset. I'm 1514 01:27:02.439 --> 01:27:06.000 looking at my kids and you know, they're getting into 1515 01:27:06.119 --> 01:27:10.560 dev and they make significant use of those AI tools. 1516 01:27:11.079 --> 01:27:14.600 So I definitely think that there's a possibility that AI 1517 01:27:14.800 --> 01:27:18.760 tools may reduce the amount of packages that we import 1518 01:27:18.960 --> 01:27:22.600 because they they'll write those one shot type codes for 1519 01:27:22.760 --> 01:27:26.880 us that we often need instead of you know important. 1520 01:27:27.720 --> 01:27:32.319 And then what will happen is that a box will 1521 01:27:32.319 --> 01:27:33.199 spread everywhere. 1522 01:27:35.039 --> 01:27:36.520 Yeah, that's the thing is That's why I said it 1523 01:27:36.560 --> 01:27:38.600 takes the senior mindset because you have to know to 1524 01:27:38.680 --> 01:27:40.359 test it, you have to know to determine if it's 1525 01:27:40.399 --> 01:27:43.399 slop or if it's real. Because depending on the day, 1526 01:27:43.479 --> 01:27:45.439 you know, when they update to a new model or 1527 01:27:45.680 --> 01:27:48.119 you know, do the revisions. I'll have a day where 1528 01:27:48.119 --> 01:27:51.960 I'm coding with GPT four. Oh, and you know it's 1529 01:27:52.039 --> 01:27:54.640 just like banger after banger and I'm like wow, And 1530 01:27:54.760 --> 01:27:57.399 then a day or two later, I'll be asking you 1531 01:27:57.520 --> 01:28:01.000 questions that might even be simpler or whatever, and it'll 1532 01:28:01.039 --> 01:28:03.000 turn out just absolute crap, and it's like, Okay, I 1533 01:28:03.039 --> 01:28:04.000 got to write this myself. 1534 01:28:05.359 --> 01:28:10.560 I think that another aspect of the reuse is that, 1535 01:28:11.079 --> 01:28:13.319 like if you're your own person, like if I'm just 1536 01:28:13.359 --> 01:28:15.960 writing code for myself, I don't mind writing some new 1537 01:28:16.039 --> 01:28:18.840 stuff and using that because like I'm the one who's 1538 01:28:18.840 --> 01:28:20.680 going to have to maintain. If you're working in a company, 1539 01:28:21.680 --> 01:28:24.039 I don't really you know, if I ran a large company, 1540 01:28:24.079 --> 01:28:27.439 I wouldn't want a hundred copies of the same thing 1541 01:28:27.640 --> 01:28:31.279 written by ten different people, even if they're using AI 1542 01:28:31.399 --> 01:28:33.760 to do it more quickly, because there's going to be 1543 01:28:33.800 --> 01:28:36.199 different bugs, there's going to be more investigation. So part 1544 01:28:36.279 --> 01:28:39.560 of the sort of the reuse is being intentional about 1545 01:28:39.560 --> 01:28:43.119 what you reuse and when you do reuse things. Like 1546 01:28:43.479 --> 01:28:45.600 the great thing in the JAVASCRPT ecosystem is we have 1547 01:28:45.680 --> 01:28:49.000 tons of choice. The challenges that we have tons of choice, 1548 01:28:49.039 --> 01:28:51.520 So at least like within an organization, you should try 1549 01:28:51.560 --> 01:28:54.680 and rein in that choice a little bit and say, well, okay, 1550 01:28:54.760 --> 01:28:58.760 we're going to use one version of X, Like, let's 1551 01:28:58.800 --> 01:29:01.279 not pick ten different ones because now we've just increased 1552 01:29:01.319 --> 01:29:03.640 our surface area in our risks by ten times. We're 1553 01:29:03.640 --> 01:29:06.399 going to pick one. We're going to reuse it. And 1554 01:29:06.760 --> 01:29:10.199 you know that's one way of continuing to maximize the 1555 01:29:10.279 --> 01:29:13.399 value you get to reuse. But you know, being intentional 1556 01:29:13.439 --> 01:29:15.880 about the dependencies you have in your application and as 1557 01:29:15.880 --> 01:29:19.319 an organization, managing the risk so that you get a 1558 01:29:19.359 --> 01:29:22.840 good balance between benefits to reuse versus the code thought 1559 01:29:22.960 --> 01:29:23.560 in your code. 1560 01:29:24.439 --> 01:29:25.640 If we bring it, if we bring it back to 1561 01:29:25.680 --> 01:29:27.399 the pillars, you know, if you look at every single 1562 01:29:27.439 --> 01:29:30.359 one of those pillars a key ingredient, and every single 1563 01:29:30.399 --> 01:29:34.079 one of those is intentionality, right, it's you know, get 1564 01:29:34.159 --> 01:29:37.159 you to stop and think about your code in some 1565 01:29:37.359 --> 01:29:39.680 aspect of it. You know, what are you testing? What 1566 01:29:39.960 --> 01:29:40.960 dependencies are you using? 1567 01:29:41.239 --> 01:29:41.399 Right? 1568 01:29:41.720 --> 01:29:44.199 How are your tasks broken down? Right? 1569 01:29:44.439 --> 01:29:45.600 All of it is just. 1570 01:29:45.880 --> 01:29:50.439 About this, this notion of being very very intentional about 1571 01:29:50.520 --> 01:29:54.439 what you're doing with your application. Dependencies are no different. 1572 01:29:54.640 --> 01:29:57.640 Don't just pick a dependency because it exists. Pick a 1573 01:29:57.720 --> 01:29:59.880 dependency because it does what you need it to do 1574 01:30:00.239 --> 01:30:03.760 the way you need it to do it right. And 1575 01:30:04.279 --> 01:30:08.520 you know, and understand what it's doing. And it doesn't 1576 01:30:08.520 --> 01:30:10.960 matter if you're having AI write your code. It's the 1577 01:30:11.039 --> 01:30:13.800 same thing, right, you have to be very intensible about it, 1578 01:30:14.359 --> 01:30:16.520 about what you're trying to accomplish. 1579 01:30:17.000 --> 01:30:19.159 Guys, I need to do. 1580 01:30:19.279 --> 01:30:19.479 Yeah. 1581 01:30:19.600 --> 01:30:22.479 Unfortunately, it's about time for me. So I just want 1582 01:30:22.560 --> 01:30:25.239 to say thank you very much for Johnning. I Fortunately 1583 01:30:25.239 --> 01:30:27.279 I would stay longer, but at this point I really 1584 01:30:27.319 --> 01:30:27.840 need to drop. 1585 01:30:28.520 --> 01:30:31.000 Okay, thank you very much for coming on. Will you 1586 01:30:31.079 --> 01:30:32.560 are going to be a guest on our show to 1587 01:30:32.640 --> 01:30:34.960 talk about something else in any event, pretty soon, so 1588 01:30:35.079 --> 01:30:37.359 we'll see you then. So thank you, thank you very 1589 01:30:37.439 --> 01:30:40.000 much for coming on today. And I'm going to push 1590 01:30:40.119 --> 01:30:42.760 us the rest of us into picks anyway. We will 1591 01:30:42.920 --> 01:30:46.600 just have to invite you over to talk more about 1592 01:30:46.600 --> 01:30:49.600 the pillars, because we literally made it halfway. We made 1593 01:30:49.640 --> 01:30:52.720 it into the middle of pillar number five, so now 1594 01:30:52.800 --> 01:30:55.039 we have the rest of pillar number five and then 1595 01:30:55.399 --> 01:30:58.119 six through nine, and this is such a great conversation. 1596 01:30:58.439 --> 01:31:02.239 I'm so happy that it's turning out this way. So 1597 01:31:02.439 --> 01:31:06.119 thank you, Matteo and uh and see you in a bit, 1598 01:31:06.439 --> 01:31:08.760 in like a few more in a few weeks. 1599 01:31:09.399 --> 01:31:10.600 Bye bye bye bye. 1600 01:31:12.039 --> 01:31:17.960 Bye, and you guys, so again I'm going to push 1601 01:31:18.039 --> 01:31:19.159 us to pigs a J. 1602 01:31:19.359 --> 01:31:23.000 Do you want to go first, Sure, I've got a couple. 1603 01:31:23.439 --> 01:31:26.279 So I'll go ahead and throw out my link to 1604 01:31:26.479 --> 01:31:29.840 this show two six implementation. If you have an application 1605 01:31:30.119 --> 01:31:35.079 where you need to be doing multiple shaws in a row, this, 1606 01:31:35.640 --> 01:31:40.960 this is the best implementation that exists in javascripts. At 1607 01:31:41.079 --> 01:31:44.960 least there might be one that's just as good, but 1608 01:31:45.079 --> 01:31:47.079 I was not able to find it. So I had 1609 01:31:47.119 --> 01:31:52.840 to publish this this and and it has been tested extensively, 1610 01:31:53.000 --> 01:31:58.520 so I am very you know I I dollars are 1611 01:31:58.600 --> 01:32:02.960 on the line with it. But anyway, so I'll I'll 1612 01:32:03.039 --> 01:32:05.960 do that just as a self promo since I since 1613 01:32:06.000 --> 01:32:09.720 I talked about it, because yeah, if web crypto works 1614 01:32:09.720 --> 01:32:11.720 because you only need to do one or two, that's great. 1615 01:32:12.479 --> 01:32:14.640 But the other the legacy modules that are out there, 1616 01:32:14.680 --> 01:32:16.960 I just I would not recommend them because they're they're 1617 01:32:17.119 --> 01:32:20.680 doing all this weird Browser five stuff or like yeah, 1618 01:32:20.800 --> 01:32:23.479 so they're just they're old, they're old, they're dated, they 1619 01:32:23.560 --> 01:32:28.119 need to be replaced. And uh yeah, so go put 1620 01:32:28.159 --> 01:32:30.039 the first star on there if you want to. And 1621 01:32:30.159 --> 01:32:32.880 then I another thing I'm gonna pick. We're heading into 1622 01:32:33.039 --> 01:32:37.199 winter so we're we're in this season right here where 1623 01:32:37.239 --> 01:32:42.880 I am of nearly perfect temperature, which the weather's been 1624 01:32:42.920 --> 01:32:45.520 really odd this year and the cycle of it's been 1625 01:32:45.640 --> 01:32:48.199 kind of strange, but the last week or two has 1626 01:32:48.239 --> 01:32:51.800 been pretty perfect temperature. We're heading into the thirties this week, 1627 01:32:51.960 --> 01:32:57.000 so it's in below freezing even so that's that as 1628 01:32:57.079 --> 01:32:59.560 soon as it came, it's over. That's that's how Utah is. 1629 01:32:59.680 --> 01:33:02.640 It's like your spring and your fall are very very 1630 01:33:02.800 --> 01:33:05.680 narrow bands. Like even two weeks ago it was up 1631 01:33:05.720 --> 01:33:08.199 in the eighties. This week it's down in the thirties. 1632 01:33:08.319 --> 01:33:11.439 So that's how it goes. But with it becoming winter, 1633 01:33:12.880 --> 01:33:16.600 static shock is a thing, at least for us here 1634 01:33:16.680 --> 01:33:20.520 in this dry climate. And a buddy of mine introduced 1635 01:33:20.560 --> 01:33:24.359 me to these grounding mats, and they sell them as 1636 01:33:24.560 --> 01:33:28.239 kind of woo woo hocus pocus, like it's gonna alleviate 1637 01:33:28.399 --> 01:33:32.479 your back playing pain problems while you sleep or carry 1638 01:33:32.479 --> 01:33:35.520 your depression, which I don't believe that the grounding mat 1639 01:33:35.640 --> 01:33:37.720 is gonna do any of that. If you do believe that, 1640 01:33:38.640 --> 01:33:44.079 i'd be curious to know why. But and honestly, I 1641 01:33:44.119 --> 01:33:45.840 actually would be curious to know if there's is there 1642 01:33:45.920 --> 01:33:47.520 some sort of science behind it or some sort of 1643 01:33:48.039 --> 01:33:53.079 uh like actual uh what lived experiences or whatever, But 1644 01:33:53.600 --> 01:33:55.720 but I get I got them, and I've got one 1645 01:33:55.760 --> 01:33:59.279 for my feet and one for my hands, just because 1646 01:33:59.359 --> 01:34:02.640 I start to develop this fear of like touching the keyboard, 1647 01:34:02.640 --> 01:34:04.399 because every time I did, I mean, it was a 1648 01:34:04.479 --> 01:34:07.039 heavy shock. It wasn't just like a little like, oh, 1649 01:34:07.319 --> 01:34:10.319 you know, I touched your sweater. It would really build up. 1650 01:34:10.479 --> 01:34:13.279 And so I got these grounding mats so that I 1651 01:34:13.960 --> 01:34:18.920 don't shock things. Also, real story about electric shock. I 1652 01:34:19.000 --> 01:34:25.039 took my home network down for two days, and I 1653 01:34:25.119 --> 01:34:27.439 kept on unplugging things and replugging them, and then it 1654 01:34:27.479 --> 01:34:29.359 would work for another hour and it would go down again. 1655 01:34:30.359 --> 01:34:34.239 It turned out there was a network switch that was 1656 01:34:34.479 --> 01:34:37.560 connected to my desk, and I believe that what had 1657 01:34:37.640 --> 01:34:41.359 happened was that I had inadvertently touched that one of 1658 01:34:41.439 --> 01:34:43.880 the cables that went to the network switch. It had 1659 01:34:43.920 --> 01:34:46.680 gotten into a bad state where it was just spitting 1660 01:34:46.720 --> 01:34:50.600 out some sort of packet. I honestly believe it was 1661 01:34:50.640 --> 01:34:54.319 from static shock, because I had unplugged a bunch of 1662 01:34:54.399 --> 01:34:56.600 other things, but I'd missed that one switch. And when 1663 01:34:56.640 --> 01:35:00.000 I finally found that, oh, I haven't actually power site 1664 01:35:00.239 --> 01:35:01.760 this thing like I thought I had. I think I 1665 01:35:01.840 --> 01:35:03.920 had power cycled it, but it had a USB connection 1666 01:35:04.079 --> 01:35:07.840 so it would still had power from the USB or 1667 01:35:07.920 --> 01:35:11.199 something like that. But anyway, I unplugged it, replugged it, 1668 01:35:11.439 --> 01:35:13.760 and then I didn't have those network problems anymore. Very 1669 01:35:13.920 --> 01:35:18.159 very weird situation, but I think just getting shocked flipped 1670 01:35:18.159 --> 01:35:22.399 a bit. So it also could potentially protect your electronics 1671 01:35:22.880 --> 01:35:27.319 from malfunction having one of these grounding pads. So I 1672 01:35:27.439 --> 01:35:30.640 linked to one that it actually feels nice. 1673 01:35:30.680 --> 01:35:31.079 It doesn't. 1674 01:35:31.399 --> 01:35:35.359 It doesn't feel cheap and junkie. It has a it 1675 01:35:35.479 --> 01:35:37.520 feels like real leather. I don't know if it is, 1676 01:35:37.600 --> 01:35:40.279 but it it feels like real leather. And it's very 1677 01:35:40.399 --> 01:35:44.640 very effective in terms of if I'm using it, I'm 1678 01:35:44.680 --> 01:35:47.840 not constantly shocking everything on my desk. If I'm not 1679 01:35:48.079 --> 01:35:50.680 using it, or like walk away on the other side 1680 01:35:50.680 --> 01:35:52.000 of the room and come back, then you know, I 1681 01:35:52.079 --> 01:35:54.760 put my hand down, and of course I shocked myself anyway, 1682 01:35:55.159 --> 01:35:57.720 grounding mats who knew? Who knew? That could be a pick, 1683 01:35:57.840 --> 01:36:01.640 but it is. And that's what I got for you 1684 01:36:01.680 --> 01:36:02.079 all today. 1685 01:36:03.920 --> 01:36:07.079 Excellent. So now I'll go with my picks. I actually 1686 01:36:07.199 --> 01:36:09.920 have two picks. So my first pick is we watched 1687 01:36:10.159 --> 01:36:15.800 on Netflix the limited series called Monsters. The Lyle and 1688 01:36:16.079 --> 01:36:19.640 Eric Menandez Story. This is a pretty famous and pretty 1689 01:36:19.720 --> 01:36:24.439 gruesome story from the end of the eighties. I think 1690 01:36:24.479 --> 01:36:27.439 it happened. The actual event happened in nineteen eighty one 1691 01:36:28.199 --> 01:36:32.520 about these two brothers that basically executed their parents and 1692 01:36:33.279 --> 01:36:35.600 they were caught. They went on, they went to a trial. 1693 01:36:35.640 --> 01:36:39.439 I won't spoil the rest of the story. There's actually 1694 01:36:39.600 --> 01:36:41.640 three ways. The funny thing is that there are actually 1695 01:36:41.760 --> 01:36:47.560 three ways to watch it on Netflix. There's the limited series, 1696 01:36:47.640 --> 01:36:54.039 which is a dramatization of the story, There's a documentary series, 1697 01:36:54.199 --> 01:36:59.159 and then there's a documentary movie. We watched the series 1698 01:36:59.520 --> 01:37:02.079 and in enjoyed it very much, and that's the thing 1699 01:37:02.159 --> 01:37:05.760 that I would recommend the most. It's well played, well written, 1700 01:37:07.079 --> 01:37:12.239 it's it's just it's just good, pretty good television. Afterwards, 1701 01:37:12.640 --> 01:37:16.279 we try to watch a documentary series because we were 1702 01:37:16.359 --> 01:37:19.119 kind of interested in the story, but it, I don't know, 1703 01:37:19.239 --> 01:37:21.600 it just went into way too many details for us. 1704 01:37:22.039 --> 01:37:25.520 So instead we watched the documentary movie, which was interesting 1705 01:37:25.600 --> 01:37:28.840 in the context of the series we just watched. But again, 1706 01:37:29.239 --> 01:37:32.840 if you're gonna watch something and just the one thing, 1707 01:37:33.439 --> 01:37:38.560 do just watch the limited series again. It's called Monsters 1708 01:37:38.640 --> 01:37:42.239 the Lylon Eric Menedde's story, and it's it's it's a 1709 01:37:42.279 --> 01:37:45.520 pretty good story. The one thing interesting about it is 1710 01:37:45.600 --> 01:37:49.359 that recently, I think the governor California, I believe, said 1711 01:37:49.399 --> 01:37:54.720 that he's reviewing their sentences because and people are saying 1712 01:37:54.760 --> 01:37:57.359 that it's potentially because of the stories that came out 1713 01:37:57.439 --> 01:37:59.800 due to these all these shows and all the the 1714 01:38:00.079 --> 01:38:03.279 ussion about them, which is kind of interesting how art 1715 01:38:03.439 --> 01:38:07.479 impacts life, I guess in a sense anyway, So that's 1716 01:38:07.560 --> 01:38:12.800 my first pick. My second pick is things have been 1717 01:38:13.119 --> 01:38:15.520 it's kind of people have stopped talking about it, maybe 1718 01:38:15.600 --> 01:38:18.319 because of the elections in the US or maybe people 1719 01:38:18.479 --> 01:38:20.760 just moved on. But there was a whole lot of 1720 01:38:20.880 --> 01:38:26.760 craziness around WordPress, like it kind of seemed like the 1721 01:38:26.880 --> 01:38:32.239 guy who's running automatic who is like the what's it called, 1722 01:38:32.439 --> 01:38:36.800 what's it called the Benevolent Dictator of WordPress, which is 1723 01:38:37.159 --> 01:38:41.319 Matt Mullenweg I think his name is pronounced seemly kind 1724 01:38:41.359 --> 01:38:43.680 of went off the rails. I won't go into the 1725 01:38:43.880 --> 01:38:48.000 entire story. It's pretty out there. A lot of crazy 1726 01:38:48.079 --> 01:38:52.239 things happened, and if you are curious about what actually 1727 01:38:52.359 --> 01:38:57.279 went down in what's potentially still going on, the one 1728 01:38:57.640 --> 01:39:00.680 video that I would recommend to learn everything about it, 1729 01:39:01.319 --> 01:39:05.800 at least everything as was as of about two weeks ago, 1730 01:39:06.600 --> 01:39:11.039 is a video made by THEO also known as THEO 1731 01:39:11.159 --> 01:39:16.479 three GG. It's actually in his throwaways channel. We'll post 1732 01:39:16.520 --> 01:39:21.720 a link. He actually spoke with Dan Sottman, another podcaster 1733 01:39:21.960 --> 01:39:27.600 streamer a bit less technical and explained to him the 1734 01:39:27.680 --> 01:39:30.319 whole thing. And THEO was kind of involved in it 1735 01:39:30.760 --> 01:39:35.239 because he actually spoke and interviewed Matt In to the 1736 01:39:35.359 --> 01:39:40.319 extent that his videos became part of the depositions in 1737 01:39:40.479 --> 01:39:45.359 the ongoing lawsuit that's related to this whole story. So again, 1738 01:39:45.439 --> 01:39:49.000 if you're interested in this craziness and wackiness in the 1739 01:39:49.119 --> 01:39:53.640 open source world and where open source can go in 1740 01:39:54.039 --> 01:39:58.399 bad situations, then it's a pretty interesting video to watch 1741 01:39:58.479 --> 01:40:02.560 and I recommend. So these are my two picks for today, 1742 01:40:02.920 --> 01:40:05.239 and i'll and i'll post a link to the links 1743 01:40:05.279 --> 01:40:09.359 to both of them. How about you, James, do you 1744 01:40:09.439 --> 01:40:10.399 have any picks for us? 1745 01:40:13.039 --> 01:40:15.439 Let's see. Well, first of all, I'm sorry if I 1746 01:40:15.520 --> 01:40:17.640 get any audio. My earbuds just died, so I'm on 1747 01:40:17.840 --> 01:40:19.000 laptop speakers now. 1748 01:40:18.960 --> 01:40:20.439 So there might be some echo. 1749 01:40:20.600 --> 01:40:25.279 I'm apologize for that. Let's see picks for for today. 1750 01:40:26.279 --> 01:40:31.439 Next week, we've got note comf EU happening in Iowa. Uh, 1751 01:40:32.119 --> 01:40:35.600 it's always my favorite time of year, getting back, getting 1752 01:40:35.680 --> 01:40:39.760 back to Ireland. We're actually returning to Waterford Castle. It's 1753 01:40:40.520 --> 01:40:45.479 the conference is an actual castle, you know, it's just 1754 01:40:45.560 --> 01:40:50.640 an absolutely wonderful, fantastic venue. There's still some tickets available, 1755 01:40:51.439 --> 01:40:52.960 you know. I know, folks from the US, it's maybe 1756 01:40:52.960 --> 01:40:55.319 a little a little harder to get over there that 1757 01:40:55.640 --> 01:40:57.119 you know, last minute, but if you're over there in 1758 01:40:57.159 --> 01:41:00.520 Europe and you have the time available, it's absolutely fantastic conference. 1759 01:41:01.319 --> 01:41:07.159 I'm gonna be talking about, uh, cross run time compatibility. 1760 01:41:07.479 --> 01:41:10.439 So all this effort, like Dino to act like note 1761 01:41:10.600 --> 01:41:13.000 bun working BacT like note workers is trying to act 1762 01:41:13.079 --> 01:41:15.600 like note how do we ensure that the all these 1763 01:41:15.640 --> 01:41:17.760 different run times work the same when it comes to like, 1764 01:41:17.880 --> 01:41:19.760 you know, standard web APIs that kind of thing. So 1765 01:41:19.800 --> 01:41:21.439 I'm gonna be talking through a lot of the challenges 1766 01:41:21.560 --> 01:41:26.680 that that all these different run times have to actually 1767 01:41:26.760 --> 01:41:30.199 make sure that they're compatible with the language like JavaScript 1768 01:41:30.239 --> 01:41:33.159 that allows you to basically do whatever you want. So 1769 01:41:33.239 --> 01:41:35.079 that'll be that'll be a fun talk. But the other 1770 01:41:35.239 --> 01:41:38.760 other side of it, and this is just my personal side, 1771 01:41:38.920 --> 01:41:41.560 my son is going. My son has been a contributor 1772 01:41:41.600 --> 01:41:43.199 to Note for a couple of years. He's doing his 1773 01:41:43.279 --> 01:41:47.159 own talk there with with with another person, Claudio. We're 1774 01:41:47.199 --> 01:41:48.680 gonna be talking about the work that they've been doing 1775 01:41:48.760 --> 01:41:54.640 to improve node uh release downloads based on cloud flare 1776 01:41:54.800 --> 01:41:56.960 R two and some of the other some of the 1777 01:41:57.039 --> 01:41:58.800 other work that they've been they've been working on. So 1778 01:42:00.239 --> 01:42:04.159 if you have time, go, we'd love to meet folks there. 1779 01:42:04.359 --> 01:42:11.680 And that's the family that nodes together, stays together. Cool 1780 01:42:11.760 --> 01:42:13.159 And how about you, Michael. 1781 01:42:13.800 --> 01:42:16.359 H Yeah, I'll my first one. I'll just agree with 1782 01:42:16.479 --> 01:42:19.279 James not you. Next week is going to be fantastic. 1783 01:42:20.039 --> 01:42:22.359 The other thing I've been doing lately is spending time, 1784 01:42:22.479 --> 01:42:24.840 like learning a little bit more about AI, trying to 1785 01:42:25.039 --> 01:42:29.199 use the libraries from JavaScript. And the great thing is 1786 01:42:29.279 --> 01:42:32.840 often like JavaScript or Typescript is the second language supported. 1787 01:42:32.920 --> 01:42:35.720 So if you look at a Lama Lamadex lang chain, 1788 01:42:35.760 --> 01:42:39.520 which we're all leading libraries in the AI space, they 1789 01:42:39.600 --> 01:42:42.439 obviously all start with Python, because really data science came 1790 01:42:42.479 --> 01:42:44.079 out of that that sort of space, and that's the 1791 01:42:44.159 --> 01:42:47.359 language I use. But most of the leading libraries also 1792 01:42:47.439 --> 01:42:50.000 then support Typescript is their second language, and I think 1793 01:42:50.039 --> 01:42:54.319 that shows a recognition of the AI ecosystem that like 1794 01:42:54.479 --> 01:42:57.279 JavaScript and typescript is going to be an important player 1795 01:42:57.359 --> 01:43:00.399 in terms of consuming those services. In terms of my 1796 01:43:00.520 --> 01:43:03.399 pick I've been looking at this week, it's the b 1797 01:43:03.520 --> 01:43:06.840 agent framework. It's actually one which started life as a 1798 01:43:06.880 --> 01:43:09.439 typescript instead of Python, which is nice to see as 1799 01:43:09.479 --> 01:43:12.680 a node developer that somebody started with a JavaScript implementation. 1800 01:43:13.520 --> 01:43:16.760 It lets you write agents that call functions more easily. 1801 01:43:16.800 --> 01:43:19.359 So I've been playing around with that, and if you're 1802 01:43:19.399 --> 01:43:24.000 interested in you know, Node and consuming AI from JavaScript typeescript, 1803 01:43:24.359 --> 01:43:26.359 I throw that over as my pick to go take 1804 01:43:26.399 --> 01:43:26.840 a look at that. 1805 01:43:28.600 --> 01:43:31.119 Very cool. Now, before we wrap up, if people want 1806 01:43:31.199 --> 01:43:33.159 to get in touch with you guys, so talk about 1807 01:43:33.199 --> 01:43:35.359 what we talked about today. I don't know if you 1808 01:43:35.520 --> 01:43:39.000 still do consulting work or in general just to speak 1809 01:43:39.039 --> 01:43:41.600 with you. How do they get in touch Michael, what's 1810 01:43:41.640 --> 01:43:42.880 the best way to contact. 1811 01:43:42.760 --> 01:43:45.520 I think you know Twitter? My handle's there. MH tauson one. 1812 01:43:46.079 --> 01:43:47.399 You can just reach out to me through that. 1813 01:43:48.479 --> 01:43:50.359 Excellent. And how about you, James. 1814 01:43:50.720 --> 01:43:55.760 Same on Twitter. I'm Jay A. Snell on Twitter and 1815 01:43:55.920 --> 01:43:59.159 on GitHub. I think we have to be following each 1816 01:43:59.199 --> 01:44:02.479 other for you to d m DM, but you know, 1817 01:44:02.600 --> 01:44:04.720 apporporate to reach out to a public chat out on 1818 01:44:04.800 --> 01:44:06.119 me on their happy chat. 1819 01:44:07.199 --> 01:44:10.680 Excellent. So guys, it's it was great having you on 1820 01:44:11.119 --> 01:44:14.560 and I really hope we can organize and schedule the 1821 01:44:15.199 --> 01:44:18.159 follow up because we do really need to cover the 1822 01:44:18.279 --> 01:44:20.479 rest of the pillars. The ones that we did were 1823 01:44:20.520 --> 01:44:24.199 so great. Thank you for coming on, and to all 1824 01:44:24.279 --> 01:44:27.600 our listeners, thank you for listening in and goodbye.