The Comeback of RPC: SolidJS, TanStack, and the Future of JavaScript Frameworks with Ryan Carniato & Tanner Linsley - JSJ 691의 전체 녹취록

00:04:16.439 good living now. 76 00:04:17.079 --> 00:04:19.399 So yeah, so what is your business model for that? 77 00:04:19.439 --> 00:04:25.480 Then? Well, it's it's different than most others, I think, 78 00:04:25.519 --> 00:04:31.680 so I abhor VC around oss. I've done venture capital 79 00:04:31.720 --> 00:04:37.040 for my last company, and I've also bootstrapped plenty of things. 80 00:04:37.839 --> 00:04:39.600 I didn't want to do that for tanse Dec. So 81 00:04:40.240 --> 00:04:45.199 Tensex basically run like a media company right now, as 82 00:04:45.240 --> 00:04:51.040 like a business side of things, so marketing, advertising, partnership, 83 00:04:51.160 --> 00:04:55.439 brand deals and the like. And that's how tanse Dec 84 00:04:56.000 --> 00:05:01.720 is making money and paying both me and also now 85 00:05:01.800 --> 00:05:05.600 contributing a lot towards contributors as well, and that's just 86 00:05:05.600 --> 00:05:07.959 going to grow over time hopefully. 87 00:05:08.000 --> 00:05:12.319 Does that mean running ads within your website, within your 88 00:05:13.040 --> 00:05:14.680 products or something else? 89 00:05:15.360 --> 00:05:18.759 Yeah, So tan stack dot com is the revenue generator 90 00:05:19.480 --> 00:05:25.160 and the libraries are just guests on the tan stack 91 00:05:25.199 --> 00:05:28.879 dot com show every day. 92 00:05:28.519 --> 00:05:32.279 That's interesting. Yeah, I'm really happy that it's working for you. 93 00:05:33.000 --> 00:05:36.439 Yeah, it's working so far, so we'll we'll see. I 94 00:05:36.439 --> 00:05:40.839 don't know if it's scalable or not, but it works 95 00:05:40.879 --> 00:05:43.240 for me, and I think that's that's good enough for now. 96 00:05:43.319 --> 00:05:46.680 And how about you, Ryan, how are things with you? 97 00:05:46.720 --> 00:05:47.160 Pretty good? 98 00:05:47.839 --> 00:05:52.279 I've been at Century now for almost a year, so okay, Yeah, 99 00:05:52.399 --> 00:05:54.959 like this week coming up marks a year Century So 100 00:05:55.800 --> 00:06:00.360 they've been great, been able to obviously support my U, 101 00:06:00.879 --> 00:06:02.240 R and D. I've been doing a lot this year 102 00:06:02.240 --> 00:06:05.759 because I've been working a lot of new areas kind 103 00:06:05.800 --> 00:06:10.720 of for upcoming releases of Solid and and they've been 104 00:06:10.720 --> 00:06:12.879 supporting lots of other ways. I've been getting closer with 105 00:06:12.920 --> 00:06:14.319 the syntax FM guys. 106 00:06:15.160 --> 00:06:16.600 I was gonna ask if you worked with them. 107 00:06:17.079 --> 00:06:20.040 Yeah, So we've been talking about how to up my 108 00:06:20.079 --> 00:06:24.199 game on video content and different kinds of media stuff 109 00:06:24.319 --> 00:06:25.399 like better promotion. 110 00:06:25.759 --> 00:06:28.720 So I'm guessing they told you you need to make 111 00:06:28.759 --> 00:06:29.879 longer videos. 112 00:06:30.480 --> 00:06:33.759 Yeah, that's funny, No, they were. 113 00:06:34.120 --> 00:06:36.199 Everyone's been really stoked on those shorter videos that I've 114 00:06:36.199 --> 00:06:38.399 been doing recently. They said they were like a little crunched, 115 00:06:38.800 --> 00:06:42.560 could do some more production value, but generally speaking, I 116 00:06:42.639 --> 00:06:46.439 usually stream for like five hours ish you know, maybe 117 00:06:46.439 --> 00:06:49.920 every other Friday or so. And I started in the 118 00:06:49.959 --> 00:06:53.120 last couple of months doing like ten minute videos, and 119 00:06:53.639 --> 00:06:55.319 for me, doing ten minute videos very hard. 120 00:06:55.319 --> 00:06:56.079 It's condensed. 121 00:06:56.120 --> 00:07:00.959 It's like because I picked really deep topics, but I 122 00:07:01.040 --> 00:07:03.079 just needed a place to point people too. When people 123 00:07:03.079 --> 00:07:05.600 are like, you know, signals, blah blah blah blah blah, 124 00:07:05.600 --> 00:07:07.360 you know, like complains. You know, I'm a React developer. 125 00:07:07.399 --> 00:07:09.120 I don't get why they important. It's just like, okay, well, 126 00:07:09.199 --> 00:07:11.759 can I make an FAQ basically as a video. And 127 00:07:12.199 --> 00:07:15.120 that's sort of what I've been trying to do. Find 128 00:07:15.160 --> 00:07:18.079 content that's sure enough that people will not like bulk 129 00:07:18.319 --> 00:07:22.360 looking at the whole length of the video, but then 130 00:07:22.439 --> 00:07:26.600 still get a lot of unique content in there. It's 131 00:07:26.639 --> 00:07:29.879 difficult because my expertise is I said, very very deep. 132 00:07:30.720 --> 00:07:33.759 You don't really find content like I do in most 133 00:07:34.040 --> 00:07:36.240 video content. Like you guys sometimes get really deep on 134 00:07:36.279 --> 00:07:38.519 your podcast, which is why I love this podcast. But 135 00:07:38.600 --> 00:07:42.079 a lot of video content isn't the same sort of thing. 136 00:07:42.319 --> 00:07:44.199 You know, it's either like how do you do this? 137 00:07:45.000 --> 00:07:49.720 Or it's like the most beginner intro level of stuff. 138 00:07:49.759 --> 00:07:52.759 So being able to ask the whys, I think is 139 00:07:52.800 --> 00:07:55.120 really really important and like looking at the design stuff. 140 00:07:55.160 --> 00:07:57.480 So I'm going to try and bridge that gap, you know, 141 00:07:57.519 --> 00:08:00.920 maybe pick smaller topics that I can actually talk about, 142 00:08:00.959 --> 00:08:02.879 you know, in seven to ten minutes. 143 00:08:03.439 --> 00:08:06.160 So you kind of remind me of that. I think 144 00:08:06.199 --> 00:08:08.759 it's Mark Twain who said I didn't have the time 145 00:08:08.800 --> 00:08:11.800 to write your long letters short letters, so I wrote 146 00:08:11.839 --> 00:08:15.199 you a long one. So yeah, it's exactly much much 147 00:08:15.199 --> 00:08:19.800 more challenging to create short and

concise and to the 148 00:08:19.879 --> 00:08:20.759 point content. 149 00:08:21.319 --> 00:08:23.959 Yeah, especially if you spend all your time like like 150 00:08:24.199 --> 00:08:27.759 really like like just kind of exploring ideas and stuff, 151 00:08:27.800 --> 00:08:30.279 you know, and taking stuff which way to actually come 152 00:08:30.360 --> 00:08:32.879 up to a consolidated messages way more work. I can 153 00:08:32.879 --> 00:08:35.120 stream for five hours, but then I'm like mostly done. 154 00:08:36.080 --> 00:08:38.080 The video is going to take me at least two 155 00:08:38.200 --> 00:08:40.000 or three days. 156 00:08:39.720 --> 00:08:43.559 You know, that's for sure. Well, let's put it this way. 157 00:08:43.600 --> 00:08:45.519 I think that once you get the hang of it, 158 00:08:45.679 --> 00:08:48.759 you'll be able to do it much more effectively. Maybe 159 00:08:48.759 --> 00:08:50.840 you should also consult about it with THEO. 160 00:08:51.320 --> 00:08:51.519 Yeah. 161 00:08:51.600 --> 00:08:56.279 Yeah, he's been waiting for me to like level up that. 162 00:08:56.559 --> 00:08:58.200 He was like, yeah, I just keep on doing what 163 00:08:58.240 --> 00:08:59.960 you're doing, but when it's time come see me you know, 164 00:09:00.240 --> 00:09:02.799 like better gear, better stuff, you know. 165 00:09:03.080 --> 00:09:06.399 So yeah, yeah, I did one video for for you 166 00:09:06.639 --> 00:09:11.759 Mastery a couple of years ago, And the amount of 167 00:09:11.799 --> 00:09:14.399 work it takes to get to just to put together 168 00:09:15.159 --> 00:09:18.519 simple videos is crazy. Whether it's recording, I would assume 169 00:09:18.519 --> 00:09:20.879 that once you get your setup in place, you know, 170 00:09:20.960 --> 00:09:23.799 your your software and your different artwork components and your 171 00:09:23.840 --> 00:09:25.519 speakers and all that stuff, and you know what you're doing, 172 00:09:25.559 --> 00:09:29.000 it's probably a lot quicker. But that's that's got to 173 00:09:29.039 --> 00:09:31.120 be a learning curve just in getting set up to 174 00:09:31.159 --> 00:09:32.879 do video production like that. 175 00:09:33.440 --> 00:09:36.840 Yeah, and I like editing stuff in I'm a big 176 00:09:36.879 --> 00:09:39.960 fan of fireship videos and even my articles are like that. 177 00:09:40.000 --> 00:09:42.759 I've always done a lot of meme pictures and like 178 00:09:42.759 --> 00:09:45.879 like images to back up what I'm saying, Yes, can 179 00:09:45.919 --> 00:09:47.679 I keep it going? Even my conference talks are like 180 00:09:47.720 --> 00:09:50.320 that too. So I find the video editing actuallyising a 181 00:09:50.320 --> 00:09:52.039 long time because I need to find just the perfect 182 00:09:52.200 --> 00:09:57.000 clip or the perfect like image to kind of overlay 183 00:09:57.600 --> 00:10:01.000 the different parts. So like it's like it's almost on 184 00:10:01.039 --> 00:10:04.519 like a twenty second cadence, so like it's you know, 185 00:10:04.639 --> 00:10:05.679 twenty minute video. 186 00:10:05.960 --> 00:10:07.159 You know, that's a lot of clips. 187 00:10:07.600 --> 00:10:09.399 Well, just let AI do it for you. 188 00:10:10.240 --> 00:10:11.799 Well, you know, I have the same struggle with always 189 00:10:11.840 --> 00:10:14.120 trying to find a perfect dad joke to publish on 190 00:10:14.159 --> 00:10:15.960 a daily basis and to throw in here and there 191 00:10:16.000 --> 00:10:18.279 so I can somewhat they all perfect. 192 00:10:18.279 --> 00:10:19.639 Stage, they're all perfect. 193 00:10:20.120 --> 00:10:21.840 Oh boy, I got to tell you some stories about 194 00:10:21.840 --> 00:10:24.919 how they're not always, but that's a topic for another time. 195 00:10:25.200 --> 00:10:28.039 Yeah, I think we need to finally get to the 196 00:10:28.320 --> 00:10:30.919 to the crux to the main issue. 197 00:10:31.080 --> 00:10:33.080 We had a topic for today, any topic that we're 198 00:10:33.120 --> 00:10:34.639 here to discuss, gotcha. 199 00:10:34.720 --> 00:10:39.320 So again, I'll give a brief background. A while back, 200 00:10:39.399 --> 00:10:43.519 I had this idea of le let's go even further back. 201 00:10:43.639 --> 00:10:49.000 I started noticing a certain pattern that was occurring in 202 00:10:49.080 --> 00:10:53.440 a lot of frameworks, especially as they were becoming meta frameworks, 203 00:10:53.840 --> 00:10:56.480 and that's kind of and I termed it to come 204 00:10:56.480 --> 00:10:59.919 back of RPC, and we'll talk about what RPC is 205 00:11:00.360 --> 00:11:04.799 and why it's making this comeback now. But when I 206 00:11:04.960 --> 00:11:07.559 noticed that, it occurred to me that this could be 207 00:11:07.559 --> 00:11:11.039 an interesting topic for a conference talk, which I created 208 00:11:11.080 --> 00:11:15.120 and already gave once at JS Heroes in Romania. But 209 00:11:15.200 --> 00:11:17.679 I reached out to a lot of my friends, people 210 00:11:17.799 --> 00:11:24.240 like Ryan, like Tanner, like Rich Harris and others, and 211 00:11:24.320 --> 00:11:28.720 started in Jack Harrington, whom we mentioned, and started talking 212 00:11:28.759 --> 00:11:33.080 with them about this whole thing, and I realized that 213 00:11:33.120 --> 00:11:36.840 a lot of them had very different viewpoints about what 214 00:11:36.879 --> 00:11:40.559 our PC is, how it should or should not be used, 215 00:11:41.159 --> 00:11:46.559 why it's interesting or maybe not. And what this ended 216 00:11:46.679 --> 00:11:50.799 up is this conversation here. I basically asked both Ryan 217 00:11:50.879 --> 00:11:53.519 and Tanner if they'd like to come on the show 218 00:11:53.960 --> 00:11:57.639 and talk about this, so, you know, take it away, guys. 219 00:11:57.919 --> 00:12:02.440 Yeah, I start because I feel like this starts with 220 00:12:03.240 --> 00:12:06.759 stuff that I was doing. But to be fair, this 221 00:12:06.799

--> 00:12:08.879 is stuff that Tenor definitely relates to right off the bat, 222 00:12:08.919 --> 00:12:11.360 because the first thing you hit when you're writing a 223 00:12:11.360 --> 00:12:14.759 meta framework, like the most obvious thing is actually meta 224 00:12:14.759 --> 00:12:18.759 frameworks are centered around routing, right and the router And 225 00:12:19.679 --> 00:12:21.360 I know this has nothing to do with RPC right 226 00:12:21.399 --> 00:12:22.320 off the bat, but like. 227 00:12:23.000 --> 00:12:26.279 Maybe we should define our PC before we dive into it. 228 00:12:26.559 --> 00:12:31.879 Yeah, okay, sure, A remote procedure call basically this idea 229 00:12:31.879 --> 00:12:34.639 that you can in different environments call a function from 230 00:12:34.679 --> 00:12:35.559 the other environment. 231 00:12:36.039 --> 00:12:38.320 Because I thought it was really popular comedy for a moment, 232 00:12:38.399 --> 00:12:38.960 glad read. 233 00:12:40.519 --> 00:12:44.240 I like to use a slightly different definition the way 234 00:12:44.240 --> 00:12:49.600 that I like to define it is basically as a 235 00:12:49.639 --> 00:12:55.120 method for invoking a service or obtaining data from another process, 236 00:12:55.559 --> 00:12:59.679 even on another computer across the network, using a function 237 00:12:59.799 --> 00:13:04.679 call paradigm. Are you okay with this definition? Yes, So 238 00:13:04.720 --> 00:13:07.440 it's basically it looks like a function call. It feels 239 00:13:07.519 --> 00:13:10.600 like a function call. You. It's as easy to use 240 00:13:10.639 --> 00:13:13.360 as a natural to use as a function call, but 241 00:13:13.600 --> 00:13:17.320 instead of just actually being a function call, it translates 242 00:13:17.360 --> 00:13:18.960 to an operation across the net. 243 00:13:19.120 --> 00:13:19.360 Yeah. 244 00:13:19.799 --> 00:13:22.039 The funniest thing is, like my first introduction to rpcs 245 00:13:22.080 --> 00:13:24.759 didn't feel as easy or natural to use as function calls. 246 00:13:25.200 --> 00:13:26.360 I was using a. 247 00:13:26.519 --> 00:13:31.799 Like soap in Microsoft stuff back in the early two thousands, 248 00:13:31.879 --> 00:13:34.840 And if anyone's us that it's like all XML based 249 00:13:34.919 --> 00:13:38.960 and they call they get categorized under RPC. But that 250 00:13:39.080 --> 00:13:42.679 like in my head when someone says RPC to me, traditionally, 251 00:13:42.720 --> 00:13:44.600 that's what I thought of. I thought of these like 252 00:13:45.120 --> 00:13:49.960 XML end points from like Microsoft Server from like two 253 00:13:50.039 --> 00:13:52.799 thousand and two. 254 00:13:52.879 --> 00:13:53.399 Memories. 255 00:13:53.720 --> 00:13:56.159 Yeah, I'm a bit of a history buff. I'm a 256 00:13:56.159 --> 00:14:00.440 bit of a history buff. So it's interesting because it 257 00:14:00.600 --> 00:14:04.159 was that period in time where RPC was effectively dying 258 00:14:04.840 --> 00:14:07.960 so our PC was really RPC. The term was coined 259 00:14:08.000 --> 00:14:11.960 in the eighties. It became really popular in the nineties 260 00:14:12.120 --> 00:14:17.720 with the native platforms for it like Corba or Dcom 261 00:14:18.080 --> 00:14:22.399 from Microsoft, and then the Web happened, which kind of 262 00:14:22.519 --> 00:14:27.039 killed it. Soap was an attempt to somehow continue to 263 00:14:27.120 --> 00:14:30.879 do RPC despite the Web, and we can talk about 264 00:14:30.919 --> 00:14:33.559 why the web killed RPC for a while at least, 265 00:14:34.279 --> 00:14:37.240 and now it's making a comeback in a much more 266 00:14:37.360 --> 00:14:40.600 natural way, which is in a lot of ways very 267 00:14:40.639 --> 00:14:45.159 reminiscent of how it was in the nineties, but compatible 268 00:14:45.279 --> 00:14:48.200 with the modern technologies that we use nowadays. 269 00:14:48.440 --> 00:14:51.600 Right, Yeah, yeah, I mean that sounds about right, Like 270 00:14:51.679 --> 00:14:55.039 no one was touching RPC after that early mid two 271 00:14:55.080 --> 00:14:58.840 thousands period until maybe like twenty twenty. 272 00:14:58.919 --> 00:15:03.720 Is they're like in the web technology, But. 273 00:15:03.960 --> 00:15:09.039 I mean yes, obviously, when we start designing these surver 274 00:15:09.080 --> 00:15:14.080 rendered meta frameworks where we actually have the server and 275 00:15:14.120 --> 00:15:18.240 the client being developed in the same place, you start 276 00:15:18.360 --> 00:15:21.080 going like, well, if I control both sides, why not 277 00:15:21.159 --> 00:15:22.600 like make that pipe easier. 278 00:15:23.039 --> 00:15:24.840 But I mean that was the motivation. 279 00:15:24.960 --> 00:15:28.080 The thing for me personally when I started looking at 280 00:15:28.080 --> 00:15:31.039 this stuff was I wasn't I was aware of this 281 00:15:31.159 --> 00:15:34.039 the soap stuff you know and that, But I was 282 00:15:34.080 --> 00:15:36.679 just trying to like I was looking at other meta frameworks, 283 00:15:36.840 --> 00:15:38.759 was this is the beginning of all start Like twenty 284 00:15:38.799 --> 00:15:41.159 twenty one is actually before I even really sold at 285 00:15:41.200 --> 00:15:42.799 one point zero, And I was like looking at other 286 00:15:42.840 --> 00:15:45.879 meta frameworks a bit, and I was looking like next 287 00:15:45.960 --> 00:15:50.879 JS and and mostly and like you know sapper from 288 00:15:51.200 --> 00:15:55.720 and like next and they all had these like API 289 00:15:55.919 --> 00:15:58.000 end points, like like where you'd like do this file 290 00:15:58.279 --> 00:16:03.639 based routing system with apien points. And the thing that 291 00:16:03.679 --> 00:16:04.919 was weird for me is I used to be a 292 00:16:05.000 --> 00:16:07.759 real guy for a bit, so like you would define 293 00:16:07.799 --> 00:16:11.360 like like in the file system, you'd define

I guess 294 00:16:11.360 --> 00:16:13.120 not a file system was an auto madeive. 295 00:16:12.879 --> 00:16:13.639 Filesism, but whatever. 296 00:16:13.679 --> 00:16:17.519 You you skelton out these like models essentially and API 297 00:16:17.600 --> 00:16:20.279 n points and they would describe the whole collection of 298 00:16:20.320 --> 00:16:24.080 the whole model of things, and the filesystem approached a 299 00:16:24.080 --> 00:16:26.600 lot of these APIs had taken was kind of it 300 00:16:26.600 --> 00:16:30.120 felt weird to me because you'd have like a different 301 00:16:30.159 --> 00:16:35.120 file for like the general like groups versus like group 302 00:16:35.159 --> 00:16:37.279 I D like you didn't put all the crowd commands 303 00:16:37.320 --> 00:16:41.120 together like it would like separate based on the URL path, 304 00:16:41.200 --> 00:16:45.039 not based on the conceptual model, if that makes any sense, 305 00:16:45.039 --> 00:16:47.480 Like instead of being talking about groups as a single thing, 306 00:16:47.600 --> 00:16:50.559 you would have like groups and groups slash. 307 00:16:50.600 --> 00:16:52.639 I d like it's a funny thing. 308 00:16:53.000 --> 00:16:54.960 But I was looking at these API shapes and I 309 00:16:55.000 --> 00:16:56.799 was like, this is such a hassle to like every 310 00:16:56.840 --> 00:16:59.080 time I do this to build out these files. 311 00:17:01.600 --> 00:17:03.919 I saw Remix. I think this was for me. 312 00:17:04.680 --> 00:17:07.680 They did their big reveal in spring twenty twenty one, 313 00:17:07.720 --> 00:17:10.960 and I know this, and when I saw their loaders 314 00:17:11.039 --> 00:17:13.079 and actions and the way that they doubled it up 315 00:17:13.079 --> 00:17:15.200 on the API side, I'm like, this is kind of nice. 316 00:17:15.559 --> 00:17:19.599 It's like turned into a single approach, because what was 317 00:17:19.680 --> 00:17:22.039 kind of awkward was that people would build their app 318 00:17:22.039 --> 00:17:23.960 in one folder and then they'd build their API and 319 00:17:24.000 --> 00:17:26.200 another folder, and it was getting kind of clunky. You 320 00:17:26.359 --> 00:17:28.839 do everything twice, kind of connecting it up. And they 321 00:17:28.920 --> 00:17:30.480 were like, no, you can just kind of stick it 322 00:17:30.519 --> 00:17:32.799 all in the same place, follow the same kind of pattern. 323 00:17:33.440 --> 00:17:35.799 The challenge I had Remix is because I've been working 324 00:17:35.799 --> 00:17:39.880 on routing for a while and nested routing and with 325 00:17:40.000 --> 00:17:43.279 you know, parallel data fetching and all these things. Is 326 00:17:43.680 --> 00:17:47.519 the remix loader basically said that this part of the 327 00:17:47.599 --> 00:17:51.880 UL loads this data, and that wasn't granular enough for me. 328 00:17:51.960 --> 00:17:54.039 I was working a solid gazz which is based on singles. 329 00:17:54.039 --> 00:17:57.519 So

as you can imagine, there's multiple different data sources. 330 00:17:57.519 --> 00:17:59.839 You want them to update independently, right, you want to 331 00:17:59.839 --> 00:18:03.039 be to refresh them independently. You only want to update 332 00:18:03.079 --> 00:18:05.279 certain parts of the page. Treating the whole page like 333 00:18:05.319 --> 00:18:09.680 it was like a single data flow was not particularly 334 00:18:10.279 --> 00:18:12.920 nice for me. So I was like, okay, can I 335 00:18:12.960 --> 00:18:16.759 take my kind of like route loaders, which are they're 336 00:18:16.799 --> 00:18:19.319 not really loaders, they're isomorphic. They run on both sides, 337 00:18:19.680 --> 00:18:23.440 these kind of nested rout kind of areas where you 338 00:18:23.440 --> 00:18:26.359 can fetch data and instead of you know, hitting API 339 00:18:26.440 --> 00:18:28.759 calls like we used to, instead of using one single loader, 340 00:18:28.960 --> 00:18:32.480 can we make it more ergonomic to define individual pieces 341 00:18:32.480 --> 00:18:35.759 of data you can fetch. And I was looking when 342 00:18:35.759 --> 00:18:37.200 I was doing the client side, and I'm like, I 343 00:18:37.240 --> 00:18:39.920 love this. You know I can put you know, you know, 344 00:18:40.119 --> 00:18:42.079 solid query. This is like a ten I rack in 345 00:18:42.119 --> 00:18:44.079 the conversation for a second, but like I can put 346 00:18:44.279 --> 00:18:47.519 like my different data fetching things inside this loading and 347 00:18:47.559 --> 00:18:49.799 I can manage them separately. If I'm on this page, 348 00:18:49.880 --> 00:18:53.000 can I can grab users and their posts and have 349 00:18:53.079 --> 00:18:57.519 multiple things and call them and invalidate them separately. And 350 00:18:57.559 --> 00:19:00.160 I'm like, this is a great pattern. It works on 351 00:19:00.160 --> 00:19:03.200 the server, works on the client. The only problem is 352 00:19:03.400 --> 00:19:06.240 you have to call these extra API in points. So 353 00:19:07.079 --> 00:19:10.319 I started working on a solution, which was, what if 354 00:19:10.359 --> 00:19:13.079 I could use the file system in a nicer way, 355 00:19:13.200 --> 00:19:15.599 like better than the API in points, where instead of 356 00:19:15.799 --> 00:19:18.400 being quite as bulky and like having these URLs, I 357 00:19:18.400 --> 00:19:21.240 could use like a proxy or something like where you 358 00:19:21.279 --> 00:19:24.359 could maybe make some types for an object, and based 359 00:19:24.400 --> 00:19:26.519 on what path you go through the object, it would 360 00:19:26.559 --> 00:19:28.960 construct the URL on the client and then know what 361 00:19:29.079 --> 00:19:32.039 endpoint to hit on the server. And I kind of 362 00:19:32.079 --> 00:19:35.200 put this together and I call them actions after remixes actions. 363 00:19:35.240 --> 00:19:39.079 And the difference is they weren't really exactly actions, or

364 00:19:39.119 --> 00:19:41.000 they were both actions and loaders. You could basically hit 365 00:19:41.000 --> 00:19:43.640 these URLs both on data fetching and on mutation, and 366 00:19:43.680 --> 00:19:47.559 you could call them They're just like autogeneratid APIs. And 367 00:19:48.119 --> 00:19:50.799 I remember I put that out around April. I made 368 00:19:50.839 --> 00:19:53.759 some demos around April twenty twenty one, but then Solid 369 00:19:53.799 --> 00:19:55.279 one point zero needed to get released, and I put 370 00:19:55.279 --> 00:19:59.559 it aside, and I basically was like showing people and 371 00:19:59.799 --> 00:20:01.920 talk like how cool this was going to be, but 372 00:20:02.319 --> 00:20:04.240 you know, people just like, oh, yeah, yeah, whatever, Ryan, 373 00:20:04.440 --> 00:20:07.720 and and then and then it was almost a year later. 374 00:20:08.200 --> 00:20:10.759 It could be fair half of us don't know, don't 375 00:20:11.400 --> 00:20:13.680 often don't understand what you're talking about, so. 376 00:20:13.640 --> 00:20:17.079 That that's that's perfectly fair. But some people did. 377 00:20:17.119 --> 00:20:20.480 And I was talking to someone in December or like 378 00:20:20.480 --> 00:20:22.680 around Christmas time, and they're like, oh, isn't that what 379 00:20:22.720 --> 00:20:26.920 blitz JS is. I'm like, Blitz, isn't that next JSS thing? 380 00:20:27.400 --> 00:20:29.440 And I look at it, and sure enough, that is 381 00:20:29.559 --> 00:20:33.400 actually what blitz was. I basically independently also came up 382 00:20:33.440 --> 00:20:34.960 something similar to what Blitz was. 383 00:20:34.920 --> 00:20:37.440 Which is blitz what is it? 384 00:20:37.440 --> 00:20:37.720 It was? 385 00:20:37.799 --> 00:20:40.799 It was it was kind of like a meta framework 386 00:20:40.839 --> 00:20:43.960 on top of Next. I thought it was like Redwood, 387 00:20:44.039 --> 00:20:46.119 like it was one of those more opinionated meta frameworks 388 00:20:46.160 --> 00:20:49.200 on top of Next. But eventually they just became like 389 00:20:49.240 --> 00:20:53.079 a Next plug in and kind of downscaled it because 390 00:20:53.119 --> 00:20:54.799 but originally it was like a separate product, like you 391 00:20:54.880 --> 00:20:58.839 when installed Next, you install Blitz, and it was it 392 00:20:58.880 --> 00:21:02.200 was a React meta frame essentially. But it's cool feature 393 00:21:02.319 --> 00:21:06.759 was that it had these basically kind of generated API 394 00:21:07.039 --> 00:21:09.839 functions in the same kind of way that I was describing, 395 00:21:10.799 --> 00:21:16.279 where you could just kind of put these basically API 396 00:21:16.359 --> 00:21:18.720 call things in a file folder structure and then call 397 00:21:18.759 --> 00:21:21.519 them directly without like the fetch and the ceremony around 398 00:21:21.559 --> 00:21:23.720 like that. You could just call them basically it's functions 399 00:21:23.839 --> 00:21:26.880 via like a proxy like I was talking about, because 400 00:21:27.359 --> 00:21:30.279 the cool thing that the proxy approaches you can have 401 00:21:30.279 --> 00:21:32.519 the proxy return whatever you want, so it just wraps 402 00:21:32.559 --> 00:21:35.720 the details of the fetch away from you. So it 403 00:21:35.799 --> 00:21:37.799 is kind of the beginning of this RPC thing because 404 00:21:37.799 --> 00:21:40.160 you still have the API point where you have a 405 00:21:40.160 --> 00:21:43.559 file system running telling you like basically where these functions are. 406 00:21:43.640 --> 00:21:45.559 But then you could use the path on the proxy 407 00:21:45.680 --> 00:21:49.559 like get users dot get or like whatever to actually 408 00:21:49.559 --> 00:21:53.359 construct the URL and obscure the fetching. And I know 409 00:21:53.400 --> 00:21:55.680 this is kind of crazy history, but you know, like 410 00:21:56.000 --> 00:21:57.799 beyond where we ended up, but it was important for 411 00:21:57.839 --> 00:21:59.039 me to get there because when I went back to 412 00:21:59.039 --> 00:22:01.480 solid Start and after playing with this again, by this 413 00:22:01.559 --> 00:22:04.559 time I had met Nikhil Sarah, who was kind of 414 00:22:04.799 --> 00:22:08.880 responsible for a lot of stuff in solid ecosystem. He 415 00:22:09.119 --> 00:22:11.240 did a lot of the heavy lifting on the original 416 00:22:11.240 --> 00:22:15.519 salt Start release, and he also created Vinci, which we 417 00:22:15.680 --> 00:22:18.160 used to actually base salts Start and tasks Start initially. 418 00:22:18.519 --> 00:22:21.599 And he was like, man, veat is amazing. We don't 419 00:22:21.599 --> 00:22:23.640 need to use all this proxy stuff. We can just 420 00:22:23.839 --> 00:22:27.480 use a compiler and split these things out, like even 421 00:22:27.519 --> 00:22:29.559 in the middle of the files, like it doesn't matter. 422 00:22:29.559 --> 00:22:32.440 He started doing crazy stuff where he was analyzing like 423 00:22:33.400 --> 00:22:36.279 things further down the tree and hoisting them automatically and 424 00:22:36.279 --> 00:22:38.799 doing like all this stuff. And I'm like, this is crazy. 425 00:22:38.880 --> 00:22:43.240 I can't even wrap my head around what's happening. But 426 00:22:43.519 --> 00:22:45.240 he's like, look, as long as we have a symbol, 427 00:22:45.400 --> 00:22:47.079 like some way of it's saying like this is a 428 00:22:47.839 --> 00:22:50.240 is a function call, we don't need to use the 429 00:22:50.240 --> 00:22:52.279 file system. We can just go like this is a 430 00:22:52.359 --> 00:22:55.799 server function or whatever, and we passed the function to it, 431 00:22:56.119 --> 00:22:59.920 and now that function will always be called on the server. 432 00:23:00.759 --> 00:23:03.240 This is where you guys invented bling. I think you 433 00:23:03.359 --> 00:23:04.720 called it back then, right. 434

00:23:04.680 --> 00:23:06.680 Yes, almost. 435 00:23:06.799 --> 00:23:10.079 Bling would come very soon soon when we brought Tanner in. 436 00:23:10.119 --> 00:23:15.240 On Tanner, what this I actually presented our original version 437 00:23:15.519 --> 00:23:18.640 like this at vcomp the first b COMP back in 438 00:23:19.000 --> 00:23:22.279 September twenty twenty two, and that's when people were like, oh, 439 00:23:22.480 --> 00:23:24.119 this is actually kind of cool, you know, because it 440 00:23:24.200 --> 00:23:26.920 had types like when you start having functions and you 441 00:23:26.920 --> 00:23:28.839 can write them like functions where you can just import 442 00:23:28.880 --> 00:23:31.240 them the types match up. 443 00:23:32.000 --> 00:23:35.559 Yeah, And I'll get to that because it brings an 444 00:23:35.599 --> 00:23:40.440 interesting point from my perspective about why RPC is so 445 00:23:40.519 --> 00:23:44.880 attractive and what changed, because we talked about how the 446 00:23:44.920 --> 00:23:47.839 web kind of killed RPC, so it's interesting to talk 447 00:23:47.880 --> 00:23:51.039 about how RPC was able to make this kind of comeback. 448 00:23:51.319 --> 00:23:53.640 But before we go there, Tanner, I really want to 449 00:23:53.640 --> 00:23:55.519 bring you into the conversation finally. 450 00:23:56.079 --> 00:23:59.400 So I mean, it is basically almost at that point 451 00:23:59.440 --> 00:24:04.079 because Tanner is really into types. So after I demoed 452 00:24:04.119 --> 00:24:06.559 this stuff and the type stuff, what came out in 453 00:24:07.519 --> 00:24:09.279 the world that we realized that, like, what's cool, You 454 00:24:09.319 --> 00:24:11.400 can literally write the function as is. You don't you 455 00:24:11.440 --> 00:24:13.200 know a lot of type things that graft you or whatever. 456 00:24:13.200 --> 00:24:15.640 You'd have to write these schemas were this the types 457 00:24:15.880 --> 00:24:19.839 inherent off the functions simply from importing them automatical transferred. 458 00:24:19.880 --> 00:24:21.240 You didn't have to do anything you wouldn't be doing 459 00:24:21.319 --> 00:24:25.680 usually for typing. So once once we uh basically realized that, 460 00:24:27.000 --> 00:24:31.240 uh you know, uh, I started kind of publishing it 461 00:24:31.279 --> 00:24:34.720 out there and talking to other people. I was like, man, 462 00:24:35.279 --> 00:24:37.599 I still couldn't get over how magical it felt. And 463 00:24:37.640 --> 00:24:39.599 then I looked over it Quick and I was like, 464 00:24:40.000 --> 00:24:42.039 maybe we just need a better symbol. So I was like, 465 00:24:42.160 --> 00:24:44.720 let's add a dollar sign on it. And I actually 466 00:24:44.759 --> 00:24:46.720 told the Quick guys like they didn't know I did this, 467 00:24:46.759 --> 00:24:50.039 and I was like, I was tarting to manual In 468 00:24:50.519 --> 00:24:52.599 at a conference in that fall, and I was like, man, 469 00:24:53.119 --> 00:24:55.400 I think Quick could add this. I honestly stole your 470 00:24:55.400 --> 00:24:58.240 guys's dollar sign just because it's like a good indicator. 471 00:24:58.279 --> 00:25:00.279 And I'm like, we can just like you. It's just 472 00:25:00.319 --> 00:25:01.480 the reverse of what Quick does. 473 00:25:01.559 --> 00:25:03.559 Quick it was really good at pulling out these little 474 00:25:03.559 --> 00:25:06.279 pieces on the client. This is like pulling out these 475 00:25:06.279 --> 00:25:08.720 little pieces for the server. It's just like inverse Quick 476 00:25:08.759 --> 00:25:12.200 and they added it to their meta framework within a 477 00:25:12.200 --> 00:25:14.640 month after that conversation, like they were just like, yeah, 478 00:25:14.640 --> 00:25:17.279 we already have everything here, and they did it almost immediately. 479 00:25:17.519 --> 00:25:21.359 And as said, that's when tanner Gun involved around that point. Oh, 480 00:25:21.400 --> 00:25:23.440 actually it might have been even a little bit later, 481 00:25:23.640 --> 00:25:27.240 is around when next Uh and React they were like 482 00:25:27.640 --> 00:25:30.160 saw this stuff too, and they're like, oh, and they 483 00:25:30.200 --> 00:25:33.279 came up with like use server, but it was specific 484 00:25:33.279 --> 00:25:38.440 for their for their rpcs, for their server function communication. 485 00:25:38.039 --> 00:25:41.039 Their Initially they actually had it in the fine names 486 00:25:41.039 --> 00:25:44.880 if you recall the dot server dot ts and dot 487 00:25:44.920 --> 00:25:45.839 client dot t s. 488 00:25:46.319 --> 00:25:48.480 That was that was the catalyst for me right there. 489 00:25:48.640 --> 00:25:50.359 Yeah, I mean there there was there was like a 490 00:25:50.400 --> 00:25:56.920 subtle different like put it because technically server functions start 491 00:25:56.960 --> 00:26:00.240 on the server and there's like a naming convention where 492 00:26:00.240 --> 00:26:02.079 they're like, okay, these are server, these are client, and 493 00:26:02.119 --> 00:26:06.279 these are shared. But then like it's a different scenario 494 00:26:06.359 --> 00:26:08.599 because the server stuff can be done all in a 495 00:26:08.640 --> 00:26:11.759 single pass, like in a single go. They when they 496 00:26:11.799 --> 00:26:14.680 originally came up with that, that was to denote server functions, 497 00:26:14.720 --> 00:26:19.599 but not sorry, server components, not necessarily server functions, right or. 498 00:26:19.480 --> 00:26:24.440 Like they didn't have an aultation. Use client came as 499 00:26:24.480 --> 00:26:28.519 an alternative to dot server and dot client my fine names. 500 00:26:28.799 --> 00:26:33.519 They didn't have anything for you server, which came around. 501 00:26:33.240 --> 00:26:36.680 Later, right exactly, So they started proposing this stuff and 502 00:26:37.000 --> 00:26:38.839 I mean, yeah, Tenner can jump in at

this point, 503 00:26:38.880 --> 00:26:40.839 but I think he saw what they were doing and 504 00:26:40.839 --> 00:26:42.119 it was just like, what the hell is this? 505 00:26:43.799 --> 00:26:46.200 I didn't I mean, I thought it was neat. I 506 00:26:46.240 --> 00:26:49.240 was more interested in, like what they were doing under 507 00:26:49.240 --> 00:26:52.359 the hood with like the compilation, what was actually happening 508 00:26:52.440 --> 00:26:57.039 to the build and transforming that the AST and whatnot. 509 00:26:57.160 --> 00:27:03.720 But I did not really like the approach to like 510 00:27:04.599 --> 00:27:08.880 use client use server at least for like RPC. I 511 00:27:08.920 --> 00:27:13.240 looked at it and I was excited about like, oh, 512 00:27:13.359 --> 00:27:16.720 I can just throw this token in there and all 513 00:27:16.720 --> 00:27:19.599 of a sudden creat an RPC, and like that part's cool. 514 00:27:20.400 --> 00:27:23.839 But then all these questions started bubbling up about like, Okay, 515 00:27:24.640 --> 00:27:30.000 clearly they don't believe that like configuring and RPC is 516 00:27:30.039 --> 00:27:33.839 as simple as a one string Like that's ridiculous. 517 00:27:33.960 --> 00:27:36.720 So I want to touch that briefly again to give 518 00:27:37.240 --> 00:27:40.640 a little bit of context to our listeners. So we 519 00:27:40.720 --> 00:27:45.119 talked about the fact that RPC is about invoking a 520 00:27:45.240 --> 00:27:49.039 function somewhere else as if it's a local fun a 521 00:27:49.079 --> 00:27:54.359 local function, and specifically in the context of full stack frameworks, 522 00:27:54.720 --> 00:27:59.759 it's basically invoking a server side function from client side 523 00:27:59.759 --> 00:28:03.160 code using the function called paradigm. So it looks and 524 00:28:03.200 --> 00:28:05.640 feels like a function. Now, in order to be able 525 00:28:05.720 --> 00:28:08.720 to do that, you kind of need to have, from 526 00:28:08.759 --> 00:28:12.960 my perspective, three things. First of all, you need to 527 00:28:13.000 --> 00:28:17.359 have type safety. Otherwise what's the point and going back 528 00:28:17.400 --> 00:28:21.039 to your or to your point, Ryan ab when disappeared, 529 00:28:21.079 --> 00:28:25.279 Obviously it only came into being after Typescript really went mainstream, 530 00:28:25.400 --> 00:28:32.799 because before Typescript, the whole typing thing was irrelevant. And 531 00:28:33.240 --> 00:28:37.279 the other thing that you need is to be able 532 00:28:37.319 --> 00:28:41.400 to simulate blocking you call to the remote function. You 533 00:28:41.440 --> 00:28:45.240 want to have it to feel like a local function, 534 00:28:45.319 --> 00:28:49.720 which means you don't get the execution back until that 535 00:28:49.759 --> 00:28:53.640 remote function finishes and provides a value. And we only 536 00:28:53.680 --> 00:28:55.640 got that after we got a sinkle weight. 537 00:28:56.240

--> 00:28:59.880 Basically, yeah, yeah, I mean, I'm native support of promise is, 538 00:29:00.039 --> 00:29:03.359 but more specific to this conversation, when framework started having 539 00:29:04.079 --> 00:29:05.839 tools to do what they think, which secularly you know. 540 00:29:06.160 --> 00:29:10.119 And which brings me back to the final point is ideally, 541 00:29:10.480 --> 00:29:14.599 not necessarily, but ideally you also want what you mentioned 542 00:29:14.640 --> 00:29:20.079 about vat, the ability to effectively instrument the code basically 543 00:29:20.279 --> 00:29:24.000 write something that looks like a function call, identify that 544 00:29:24.079 --> 00:29:25.920 this code is going to be running on the client, 545 00:29:26.240 --> 00:29:28.480 this code is going to be running on the server 546 00:29:28.880 --> 00:29:32.799 and generate all the magic code that makes this thing work. Basically, 547 00:29:32.839 --> 00:29:37.119 it's it's a stub and on the client and on 548 00:29:37.160 --> 00:29:41.920 the server that handles the whole networking layer underneath that 549 00:29:42.200 --> 00:29:42.960 function call. 550 00:29:43.559 --> 00:29:45.440 Now I'm mentioning that you don't. 551 00:29:45.359 --> 00:29:51.839 Necessarily have to have it because types trpc does without it, 552 00:29:52.559 --> 00:29:58.799 which makes it less magical and and also less fun. Potentially, 553 00:30:00.160 --> 00:30:03.599 going back to I want to give Tanner, I basically 554 00:30:03.640 --> 00:30:08.039 stole the mic from Tanner. So Tanner, you said that 555 00:30:08.319 --> 00:30:12.359 you looked at that the fact that they introduced this 556 00:30:12.480 --> 00:30:15.119 kind of magic string and all of a sudden it 557 00:30:15.319 --> 00:30:18.599 kind of worked, and you had thoughts about. 558 00:30:18.359 --> 00:30:27.160 That, Yeah, because like details matter eventually, details matter a lot. 559 00:30:27.480 --> 00:30:31.960 Like I think what you see is like you you 560 00:30:32.119 --> 00:30:37.079 write use server and a function, and that's that's really magical, 561 00:30:37.599 --> 00:30:40.400 and it's it's magical both in a sense of like 562 00:30:40.880 --> 00:30:44.039 it's doing a lot under the hood for you, but 563 00:30:44.119 --> 00:30:50.720 it's also a magical experience for most like basic operations 564 00:30:50.799 --> 00:30:55.400 or basic use cases. It's so simple, it's deceptively simple 565 00:30:55.519 --> 00:30:57.480 that it's like, oh, that's all it takes, right, and 566 00:30:57.519 --> 00:31:00.720 you just you put U server in there, But there's 567 00:31:00.799 --> 00:31:05.799 so many details that bubble up that you cannot get 568 00:31:05.799 --> 00:31:10.319 away from the fact that this is happening over the network. 569 00:31:10.759 --> 00:31:17.400 There are implementation details there that matter sometimes and there 570 00:31:17.559 --> 00:31:27.039 for example, yeah, caching protocol methods, header's authentication. There's there's 571 00:31:27.119 --> 00:31:31.839 like edge case flexibility that needs to be inherently in 572 00:31:31.880 --> 00:31:34.599 the system to allow you to do things that you 573 00:31:34.839 --> 00:31:38.079 maybe don't do ninety percent of the time, but you 574 00:31:38.119 --> 00:31:42.079 will need to do. One of the basic ones was 575 00:31:44.000 --> 00:31:48.640 you server defaults to a post sorry not be defaults. 576 00:31:48.680 --> 00:31:53.400 It is a post request in like next jays and 577 00:31:53.480 --> 00:31:56.359 React reacts to kind of spec right. 578 00:31:56.519 --> 00:31:59.279 You also don't have any control, like you said, either 579 00:31:59.359 --> 00:32:01.559 over the end point all the protocol. 580 00:32:01.440 --> 00:32:05.240 No or headers or anything like that. You're you can 581 00:32:05.839 --> 00:32:08.119 kind of get it some of the implementation, but only 582 00:32:08.200 --> 00:32:11.480 at like a global place. But if you wanted to 583 00:32:11.519 --> 00:32:14.559 customize any of that other stuff, you can't really do that, 584 00:32:14.759 --> 00:32:16.759 and you have to break out of the system entirely. 585 00:32:17.440 --> 00:32:21.119 And I didn't like that because immediately I was like, well, 586 00:32:21.160 --> 00:32:24.640 I want to use this with reac query, and that's 587 00:32:24.640 --> 00:32:27.720 great for cashing, But wouldn't it be great if if 588 00:32:27.759 --> 00:32:31.319 the browser could actually just cash this get request that 589 00:32:31.359 --> 00:32:35.119 I'm making, it's totally capable of doing that. And then 590 00:32:35.119 --> 00:32:39.160 there's questions of well, how is that URL formulated in 591 00:32:39.200 --> 00:32:42.039 a way that's going to be stable for the browser 592 00:32:42.039 --> 00:32:44.720 to cash, And there's lots of questions that came up 593 00:32:44.720 --> 00:32:47.640 for me around that, and I just knew at one 594 00:32:47.720 --> 00:32:51.480 point we're going to need to like ninety percent of 595 00:32:51.519 --> 00:32:54.920 the time same experience as just use server. Just create 596 00:32:54.960 --> 00:32:57.039 a function, give it some kind of a symbol, a 597 00:32:57.119 --> 00:33:00.759 dollar sign or something that would make it easy for 598 00:33:01.039 --> 00:33:04.200 a bulk of the use cases, and then have at 599 00:33:04.319 --> 00:33:08.880 least the ability or the option to expand and and 600 00:33:09.119 --> 00:33:13.599 make that configuration advanced. I just don't understand when people 601 00:33:13.680 --> 00:33:18.480 create APIs that cannot be ripped away easily or like 602 00:33:18.559 --> 00:33:22.119 dug into easily. I don't understand it. And these directives 603 00:33:22.160 --> 00:33:25.839 of use server or use cash or whatever are like 604 00:33:25.960 --> 00:33:28.160 the biggest offenders of that principle for me. 605 00:33:28.839 --> 00:33:34.000 So it's it's funny because as you

get guys may 606 00:33:34.039 --> 00:33:36.680 not know actually I started with server functions, solid uses 607 00:33:36.759 --> 00:33:42.200 use server today because compatibility with react or like conceptually 608 00:33:42.480 --> 00:33:44.759 there yes, wrapper functions are. 609 00:33:45.559 --> 00:33:49.039 By the way, like intense sex start you can write 610 00:33:49.160 --> 00:33:52.200 use server ye and you'll get the same experience. 611 00:33:52.279 --> 00:33:56.519 But it's yeah, like rapper functions are as tenders that 612 00:33:56.559 --> 00:34:01.480 are almost necessary for configuration. And that's like positively at 613 00:34:01.519 --> 00:34:07.039 least is that because this configuration comes from the client, 614 00:34:07.359 --> 00:34:09.840 wrapping is definitely something you can do, Like you can 615 00:34:10.239 --> 00:34:13.280 compose these kind of pieces on top of server functions 616 00:34:13.320 --> 00:34:17.679 because the server parts on the server, the use server, 617 00:34:17.840 --> 00:34:21.800 the server offs and represents the split between the like 618 00:34:21.880 --> 00:34:23.440 this goes on server, this goes in the client. 619 00:34:23.559 --> 00:34:25.000 So it's basically. 620 00:34:26.880 --> 00:34:29.239 One of the things that kind of enabled I'll give 621 00:34:29.239 --> 00:34:31.840 you in a second just mentioning that one of the 622 00:34:31.880 --> 00:34:34.960 things that enabled this whole thing is like you mentioned 623 00:34:34.960 --> 00:34:38.760 when we talked about VAT, is that smart bundler that's 624 00:34:39.079 --> 00:34:42.519 that's analyzing the code in any event, sees it and 625 00:34:42.559 --> 00:34:45.519 then knows to generate different code for the server and 626 00:34:45.639 --> 00:34:48.440 different code for the client from the same source code. Right, 627 00:34:49.039 --> 00:34:50.360 That's the sweet magic. 628 00:34:50.800 --> 00:34:53.119 We should talk about beat here for a little bit more, 629 00:34:53.239 --> 00:34:57.519 because the thing is at this point Tenner and I 630 00:34:57.599 --> 00:35:00.679 are talking the keel and we're like every framework could 631 00:35:00.760 --> 00:35:00.920 use this. 632 00:35:00.960 --> 00:35:01.840 Why just use this. 633 00:35:01.800 --> 00:35:05.239 Only in solid Why have you know, you know, quick 634 00:35:05.320 --> 00:35:08.760 make their own version. Why have next make their own version? 635 00:35:10.000 --> 00:35:14.360 And Antenner was like, okay, let's let's like just make 636 00:35:14.400 --> 00:35:16.679 a generic plugin for this, right, So that's where Blain 637 00:35:16.800 --> 00:35:19.760 came about. When it was like Kennedy, he picked it 638 00:35:19.800 --> 00:35:22.440 up and he was like, let's let's make this generic. 639 00:35:22.480 --> 00:35:23.880 The thing that is. 640 00:35:23.840 --> 00:35:28.239 Bling didn't quite survive in the same form because what 641 00:35:28.280 --> 00:35:32.039 we realized was

Blain was basically like a was it 642 00:35:32.079 --> 00:35:34.440 a Babel plug in. It was basically a transform. It 643 00:35:34.519 --> 00:35:41.559 basically transformed a code without bundler awareness, which does work 644 00:35:42.559 --> 00:35:45.159 a lot in this in the simple cases, but it 645 00:35:45.199 --> 00:35:49.159 doesn't work in the more complicate cases, mainly that if 646 00:35:50.159 --> 00:35:52.320 how do you register these endpoints? 647 00:35:53.039 --> 00:35:53.239 Right? 648 00:35:53.480 --> 00:35:56.880 Real apps have code splitting, so you might not load 649 00:35:56.920 --> 00:35:58.960 all the code in the client, or you might not 650 00:35:59.000 --> 00:36:02.000 load all the code on the server. And what ended 651 00:36:02.079 --> 00:36:05.840 up happening with the just doing a compiler approach was 652 00:36:06.000 --> 00:36:09.159 that we would sometimes navigate to a page on the 653 00:36:09.159 --> 00:36:13.119 client that hadn't been navigated to on the server, which 654 00:36:13.199 --> 00:36:15.800 means the endpoint wouldn't be registered yet. 655 00:36:15.639 --> 00:36:18.199 It didn't exist yet, so it didn't even occur to me. 656 00:36:18.920 --> 00:36:22.800 So like basically, this generic approach, it wasn't enough just 657 00:36:22.800 --> 00:36:25.079 to stop a babble and a compiler. We needed something 658 00:36:25.119 --> 00:36:28.239 that would actually go through the whole module graph and 659 00:36:28.960 --> 00:36:33.199 oist out these things, and it had to be bundler level. 660 00:36:33.320 --> 00:36:36.760 So this is that's that's actually why Blaine died. In 661 00:36:36.760 --> 00:36:38.480 a sense, Tannor has remade. 662 00:36:38.880 --> 00:36:42.880 It was repurposed, right. Actually, what's funny is like a 663 00:36:42.880 --> 00:36:46.519 lot of the code from Bling made it into VINI. 664 00:36:47.239 --> 00:36:50.159 Yes, yeah, yeah, I mean at the VAT. 665 00:36:50.039 --> 00:36:52.920 Level, right, And then what's funny is then eventually we 666 00:36:53.039 --> 00:36:54.400 ripped it back out. 667 00:36:54.719 --> 00:36:56.679 Right, and the other part of Vinci ended up going 668 00:36:56.679 --> 00:37:00.559 directly to VAT when VEAT adopted the environment's API, because 669 00:37:00.599 --> 00:37:04.920 we're building these things and the VAT team had, I 670 00:37:04.920 --> 00:37:07.239 guess their own problem with deployment, like the solved with 671 00:37:07.239 --> 00:37:09.440 the deployment environments, like you have cloud Flare, which is 672 00:37:09.440 --> 00:37:12.079 different than Netlify and Bursell, and you could build for 673 00:37:12.199 --> 00:37:15.800 like different outputs like workers versus pages and all these 674 00:37:15.840 --> 00:37:19.239 things people wanted to have, like you know and client preserved. 675 00:37:19.400 --> 00:37:23.599 They want to have these different environments. Vinci actually did 676 00:37:23.639 --> 00:37:26.440 that because VAT didn't. It was hard to manage these 677 00:37:26.519 --> 00:37:30.920 kind of things, and. 678 00:37:29.199 --> 00:37:31.000 That's why we created it. And in the end. 679 00:37:31.400 --> 00:37:33.960 As I said, VINCI now has kind of been dismantled, 680 00:37:34.320 --> 00:37:37.960 but the environment API now exists in Beat very similar 681 00:37:38.199 --> 00:37:40.199 seeing usage to how we used to do it in VINCI, 682 00:37:40.639 --> 00:37:45.559 and we still have the server functions plug in in 683 00:37:45.599 --> 00:37:48.400 the form of what what's under Tanstak that's now used 684 00:37:48.440 --> 00:37:51.039 both by Soul, certain tank Tack start Tanner. 685 00:37:51.320 --> 00:37:55.280 You're very polite. You raise your hand. 686 00:37:56.079 --> 00:37:59.760 Oh, I was. I was gonna say. One of your 687 00:38:00.039 --> 00:38:02.559 questions went unanswered, and I wanted to answer it before 688 00:38:02.599 --> 00:38:05.519 we went too deep into compiler land. And it was 689 00:38:05.559 --> 00:38:10.360 about type safety, and that is a massive part of 690 00:38:11.519 --> 00:38:16.159 another massive reason of why it all went this direction 691 00:38:16.239 --> 00:38:21.880 for me, and it's it's also because type safety. A 692 00:38:21.920 --> 00:38:24.599 lot of people think, well, it's just defining, you know, 693 00:38:24.880 --> 00:38:29.920 the types that this function can take on. But in 694 00:38:29.960 --> 00:38:34.360 reality you're not just writing typescript types and expecting those 695 00:38:34.400 --> 00:38:39.760 to get extracted away into validation. Because that's another that's 696 00:38:39.800 --> 00:38:42.960 another part where like just sending, just treating it like 697 00:38:43.000 --> 00:38:47.920 a function still is not totally safe. I mean, I 698 00:38:48.039 --> 00:38:49.840 like it that we that we want to get to 699 00:38:49.880 --> 00:38:52.960 this functional zintax of just calling the function and having 700 00:38:53.039 --> 00:38:57.000 it be awaited, and it's it's really nice, but under 701 00:38:57.000 --> 00:38:59.480 the hood, it's these details you need to be aware 702 00:38:59.519 --> 00:39:01.840 of them, and one of them is that you're going 703 00:39:01.840 --> 00:39:06.320 across the network. So type safety without validation is a 704 00:39:06.360 --> 00:39:11.320 complete lie. You can validate anytime you go across a 705 00:39:11.440 --> 00:39:15.960 serialization boundary, even into the URL or local storage, anywhere 706 00:39:16.400 --> 00:39:18.960 you have to validate or it's just a lie. 707 00:39:19.440 --> 00:39:22.719 So yeah, it's really I'll let you continue in a second. 708 00:39:22.719 --> 00:39:26.639 I'm just clarifying again the terminology. It's that distinction between 709 00:39:27.119 --> 00:39:31.000 dev time type safety, maybe even build time type safety 710 00:39:31.400 --> 00:39:33.800 and run time type safety. 711 00:39:33.480 --> 00:39:39.000 Static type checking

versus actually run time validation. 712 00:39:38.960 --> 00:39:43.679 And exactly in Typescript very intentionally does not do any 713 00:39:44.239 --> 00:39:47.199 run type type checking. So the fact that you're building 714 00:39:47.400 --> 00:39:51.079 on that you're leveraging Typescript types is really cool. You 715 00:39:51.119 --> 00:39:55.320 get completion, you get squiggly lines during development, but at 716 00:39:55.400 --> 00:39:59.119 runtime over the network, anything might be sent, especially if 717 00:39:59.159 --> 00:40:01.159 it's like a public point. 718 00:40:00.880 --> 00:40:03.280 Right and you know, you might feel like you're just 719 00:40:03.360 --> 00:40:07.239 writing a function and it might feel secure, But no 720 00:40:07.280 --> 00:40:09.800 one in their right mind would create a rest endpoint 721 00:40:10.280 --> 00:40:14.159 straight into their back end and not validate the inputs 722 00:40:14.199 --> 00:40:18.719 that they're getting from people. And so the same way here, 723 00:40:18.760 --> 00:40:21.840 like you you want to be validating the inputs going 724 00:40:21.840 --> 00:40:26.960 across these functions in a special way that isn't just oh, 725 00:40:27.039 --> 00:40:29.320 it's a typescript type. So I'm just going to trust 726 00:40:29.360 --> 00:40:32.360 that I'm the only one calling it and that my 727 00:40:32.480 --> 00:40:34.599 system is the only one that has access to this 728 00:40:35.039 --> 00:40:39.239 public RPC endpoint. Like all this stuff is easily reverse 729 00:40:39.320 --> 00:40:41.800 engineered and abused. 730 00:40:42.119 --> 00:40:46.480 It's even worse because when you're doing posts like straight 731 00:40:46.559 --> 00:40:51.360 on RESTful APIs, you know that you know that you're 732 00:40:51.400 --> 00:40:53.400 going to have to check the types. You're going to 733 00:40:53.480 --> 00:40:55.119 have to effectively cast the types. 734 00:40:55.440 --> 00:40:59.519 Yeah, because when you're losing the types perfectly going into 735 00:40:59.559 --> 00:41:03.199 this exactly on transform mechanism and pulling them back out 736 00:41:03.280 --> 00:41:06.960 on the server side, you know you you have to 737 00:41:06.960 --> 00:41:09.519 do the same thing coming back out. Otherwise it's like, well, 738 00:41:09.519 --> 00:41:11.800 this is just a blob of whatever, you know. 739 00:41:13.679 --> 00:41:17.039 I think, yeah, and with and and I forget if 740 00:41:17.039 --> 00:41:20.519 it was Rich Harris or Lirental who literally showed me 741 00:41:20.599 --> 00:41:25.079 an example I think where they used typescript and instead 742 00:41:25.159 --> 00:41:29.360 of a certain value pass vr PC being like saying 743 00:41:29.440 --> 00:41:32.360 just a string, they said it needs to be like 744 00:41:33.679 --> 00:41:40.880 the quote unquote quote child or quote teacher and nothing 745 00:41:40.920 --> 00:41:43.639 at run time validates that some other string is not 746 00:41:43.760 --> 00:41:48.440 passed in so you so typescript literally lies to you 747 00:41:48.519 --> 00:41:51.159 in this case if you're not careful. 748 00:41:51.079 --> 00:41:54.159 Which typescript needs to come after that, which is it 749 00:41:54.199 --> 00:41:58.920 needs to be a byproduct. And that's exactly why we 750 00:41:58.920 --> 00:42:02.400 we did two things. One we adopted Standard Schema. I mean, 751 00:42:02.440 --> 00:42:06.760 we helped kind of push standard Schema into reality. It 752 00:42:06.800 --> 00:42:09.840 was created by all the brilliant people that build these 753 00:42:09.920 --> 00:42:16.679 validation libraries like yeah, like like ZOD and type, archetype 754 00:42:16.719 --> 00:42:19.840 and stuff like that. But but we needed validation, so 755 00:42:19.880 --> 00:42:22.639 we did validation first. And what's interesting is with with 756 00:42:22.719 --> 00:42:28.320 our APIs to create our PCs, we do not allow you. 757 00:42:29.440 --> 00:42:31.119 I mean, you can do anything you want, but I mean, 758 00:42:31.159 --> 00:42:35.159 the the happy path of our API is that you 759 00:42:35.239 --> 00:42:39.719 do not get types in your server functions in your 760 00:42:39.840 --> 00:42:45.119 rpcs unless you provide validation that gives you those types. 761 00:42:45.559 --> 00:42:48.159 If you try, like, we don't have a generic API 762 00:42:48.280 --> 00:42:53.440 to just cast the the types coming back with just 763 00:42:53.519 --> 00:42:57.280 typescript because we we think it's unsafe. So that is 764 00:42:57.320 --> 00:42:59.880 the happy path. You have to use a ZOD schema 765 00:43:00.079 --> 00:43:04.400 or an archetypes or whatever to to get that validation 766 00:43:04.719 --> 00:43:06.000 and turn it into types. 767 00:43:06.800 --> 00:43:08.840 It's funny how full circle this is going. 768 00:43:09.280 --> 00:43:11.480 And this happens to me a lot, I have to admit, 769 00:43:11.519 --> 00:43:16.960 because of the lookliness. Like the reason that RPC died 770 00:43:17.000 --> 00:43:20.280 in the first place was because it was clunky to 771 00:43:21.440 --> 00:43:23.760 in my opinion, there's many reasons, but part of it 772 00:43:23.840 --> 00:43:27.079 was that it was clunky to define stuff. And like 773 00:43:27.280 --> 00:43:30.199 it's a challenge like graft Tuel going away because you 774 00:43:30.199 --> 00:43:32.239 know you're defining these like. 775 00:43:32.159 --> 00:43:33.079 To define the types. 776 00:43:34.480 --> 00:43:38.599 So people get these Jason APIs and then and the 777 00:43:38.760 --> 00:43:41.199 people did the Jason on APIs and they like, you know, 778 00:43:41.559 --> 00:43:44.079 manage themselves, but it wasn't schema basis through the code 779 00:43:44.079 --> 00:43:44.719 at run time. 780 00:43:45.280 --> 00:43:47.400 And then like but there's a lots of holes there. 781 00:43:47.519 --> 00:43:50.480 So now people have reinforced on types, which obviously again 782 00:43:50.599 -->

00:43:53.000 gets us back to RPC. But like, it's funny the 783 00:43:53.039 --> 00:43:55.159 framework author's side, like let's say like deeper on the 784 00:43:55.239 --> 00:43:57.760 UI frame side, Like say, guys like myself or people 785 00:43:57.800 --> 00:44:00.000 working on React, we're looking at this and we're like, okay, McKenna, 786 00:44:00.639 --> 00:44:04.800 this works nice. It's ergonomic as thing. People can build 787 00:44:05.159 --> 00:44:07.719 stuff on top of it if they need to. But 788 00:44:08.239 --> 00:44:10.119 I have the pieces I need to do what I 789 00:44:10.159 --> 00:44:13.880 need to mechanically, and it's and it's smooth, but then 790 00:44:14.719 --> 00:44:17.000 we we get to a point where we add back 791 00:44:17.159 --> 00:44:20.400 our own friction because of like best practices. 792 00:44:21.360 --> 00:44:23.920 So that's what it was. Kind of kind of like the. 793 00:44:25.000 --> 00:44:27.559 Nice things on the web, that's truism. 794 00:44:28.400 --> 00:44:30.639 So yeah, it's kind of it's kind of interesting because 795 00:44:30.679 --> 00:44:32.360 because like, yeah, I mean, I love, you know, the 796 00:44:32.400 --> 00:44:34.599 standard schema, A big fan of Valabot and all that 797 00:44:34.639 --> 00:44:36.280 kind of stuff, But it's but it was, it's like 798 00:44:36.280 --> 00:44:38.199 one of those things where like the people building UI 799 00:44:38.280 --> 00:44:41.039 frameworks usually maybe the meta frameworks can, but the UI 800 00:44:41.119 --> 00:44:45.039 frameworks can't. Can't generally won't push those kind of things 801 00:44:45.039 --> 00:44:48.039 on you because they're like they're not they're not in 802 00:44:48.079 --> 00:44:50.559 our range of to be enforced because people will have 803 00:44:50.599 --> 00:44:52.159 different opinions, things will change over. 804 00:44:52.039 --> 00:44:55.480 Time, too much opinion coming from right exactly. 805 00:44:55.519 --> 00:44:57.280 So it's like we. 806 00:44:57.199 --> 00:44:59.400 Being a meta framework, then you get to enforce a 807 00:44:59.480 --> 00:45:00.800 little bit more those opinions. 808 00:45:00.920 --> 00:45:04.599 Yeah, it's just tricky because meta frameworks have a shorter 809 00:45:04.800 --> 00:45:06.760 shouldn't theory have a shorter shelf life? 810 00:45:06.519 --> 00:45:07.760 Because of that, Like. 811 00:45:08.239 --> 00:45:09.960 This was always the struggle I had on was work 812 00:45:09.960 --> 00:45:12.039 on all start because I like didn't want to make 813 00:45:12.119 --> 00:45:14.800 meta framework. I just wanted to make a like a 814 00:45:15.000 --> 00:45:17.440 create React app that work on the servers. This kind 815 00:45:17.440 --> 00:45:20.280 of kind of tension is interesting for the science space. 816 00:45:20.960 --> 00:45:23.519 There was something I wanted to say. You said, there's 817 00:45:23.519 --> 00:45:25.280 three things you need for rpcs to come back. 818 00:45:25.920 --> 00:45:30.920

Yeah, I mentioned, I'll said again, maybe it'll jog your memory. Basically, 819 00:45:31.079 --> 00:45:36.239 it was a type for the underlying system to be 820 00:45:36.400 --> 00:45:39.679 typed or type safe that at least a development time. 821 00:45:39.760 --> 00:45:43.400 Otherwise there's no point. So you probably wouldn't do RPC 822 00:45:43.519 --> 00:45:47.920 if you've just got JavaScript, a weight so that you 823 00:45:47.960 --> 00:45:52.679 can quote unquote block until that remote function finishes, and 824 00:45:53.239 --> 00:45:59.599 optionally the compiler slash bundler so that you can automatically 825 00:45:59.679 --> 00:46:02.840 general rate the stub code to do to translate that 826 00:46:02.960 --> 00:46:07.599 function called into you know, do the serializations, send the 827 00:46:07.639 --> 00:46:10.840 message across the wire, do the de serialization on the 828 00:46:10.840 --> 00:46:12.559 other side and back again? 829 00:46:13.119 --> 00:46:16.039 Right yeah, yeah, And you just mentioned it twice because 830 00:46:16.760 --> 00:46:19.320 I said at the beginning I wasn't trying to build RPC. 831 00:46:19.559 --> 00:46:22.360 I think the final piece that access cemented it for 832 00:46:22.480 --> 00:46:27.679 me was the serialization part. Because we don't communicate in 833 00:46:28.039 --> 00:46:30.559 Jason anymore with these you don't. 834 00:46:31.039 --> 00:46:32.760 No, no, no, I think. 835 00:46:32.639 --> 00:46:36.480 You do, don't you the call over the wire is 836 00:46:36.519 --> 00:46:40.079 it Jason or is it something else for server functions? 837 00:46:40.199 --> 00:46:45.440 Yeah, yes, by default, yes it's Jason. Yeah. 838 00:46:45.639 --> 00:46:48.639 See didn't And this is one of the attractive to 839 00:46:48.679 --> 00:46:51.119 be though. Yeah, this is one of the attractive things 840 00:46:51.119 --> 00:46:53.679 for us time because you can trouble sides. So this 841 00:46:53.760 --> 00:46:56.360 is like react love this, we love this, framework has 842 00:46:56.360 --> 00:46:58.079 love this. This is this is where you can go 843 00:46:58.119 --> 00:47:01.519 back and to what framework wanted is. At the exact 844 00:47:01.559 --> 00:47:03.599 same time I was working on this, we were updating 845 00:47:03.599 --> 00:47:07.119 our approach to doing streaming SSR and stuff, and we 846 00:47:07.159 --> 00:47:09.920 were making it faster and more efficient. Like every framework 847 00:47:09.960 --> 00:47:14.039 has their own serializer. Some are publicly available like solid seabo, 848 00:47:15.000 --> 00:47:21.280 Marco's warp nine devalue from spelp, and we were. 849 00:47:21.119 --> 00:47:23.159 Going to need to give a little bit more context 850 00:47:23.280 --> 00:47:25.960 I think. Okay, so to some of our listeners about 851 00:47:26.079 --> 00:47:28.719 why it is that you need this sort of civilization 852 00:47:28.880 --> 00:47:29.920 for SSR. 853 00:47:29.880 --> 00:47:31.239 I think that'll be

really useful. 854 00:47:31.519 --> 00:47:32.440 Yeah, okay, sorry. 855 00:47:33.199 --> 00:47:36.000 Basically you're sending HTML, which you're like, okay, that's great, 856 00:47:36.599 --> 00:47:39.800 but the problem is now you have something ASIC so 857 00:47:41.280 --> 00:47:45.239 you can send the HTML in chunks. Let's say, so 858 00:47:45.280 --> 00:47:50.480 you're sending you know yes or it's streaming is basically 859 00:47:50.480 --> 00:47:54.880 the problem. You want to be able to not only 860 00:47:54.920 --> 00:47:58.119 send the HTML markup, but you want to be able 861 00:47:58.119 --> 00:48:01.239 to send the data across and if you wait for 862 00:48:01.280 --> 00:48:03.519 it all to finish, then just send the Jason and 863 00:48:03.559 --> 00:48:05.679 the HTML. Then you show the whole page at the end. 864 00:48:06.199 --> 00:48:09.519 But if you can, if you can send different types 865 00:48:09.559 --> 00:48:13.760 of serialization values, it's possible to send pieces of the 866 00:48:13.800 --> 00:48:16.679 app in parts and then for the client to go, oh, 867 00:48:17.360 --> 00:48:21.000 you serialize a promise, for example, and the client go okay, 868 00:48:21.159 --> 00:48:25.000 I know this data is coming. That's the most fundamental 869 00:48:25.039 --> 00:48:27.360 way of doing it, where we basically describe a promise 870 00:48:27.360 --> 00:48:29.880 over the wire. So when you know it starts hydrating 871 00:48:29.880 --> 00:48:31.480 part of the page and the whole page hasn't loaded 872 00:48:31.519 --> 00:48:34.000 in from the server, we can go okay, treat it 873 00:48:34.000 --> 00:48:36.320 like a client side promise, and we know that what 874 00:48:36.360 --> 00:48:38.920 will end up happening is actually on the same website page. 875 00:48:39.159 --> 00:48:42.599 We'll actually stream that Jason later, but then we'll when 876 00:48:42.599 --> 00:48:44.599 it comes in, we'll fulfill the promise on the client. 877 00:48:45.119 --> 00:48:50.920 So again, just to clarify the need, if I understand correctly, 878 00:48:51.079 --> 00:48:56.159 correct me if I'm wrong. It's it's your HTML intrinsic 879 00:48:56.280 --> 00:49:03.679 is intrinsically streaming. So the HTML protocol, unlike JavaScript, essentially 880 00:49:03.800 --> 00:49:06.440 you can stream it and it will just execute. The 881 00:49:06.559 --> 00:49:09.719 problem I think is the order of things is the 882 00:49:09.719 --> 00:49:14.960 fact that you that HTML streams top to bottom, whereas 883 00:49:15.119 --> 00:49:18.119 you want to be able to stream things and inject 884 00:49:18.119 --> 00:49:22.079 them in the middle of things that have already arrived. Right, 885 00:49:23.519 --> 00:49:26.719 and Tanner has raised his hand again, so interrupt. 886 00:49:26.880 --> 00:49:29.159 I just want to punctuate that and say that it's 887 00:49:29.639 --> 00:49:35.800 it's about order. It's about componentization of these calls to 888 00:49:35.800 --> 00:49:40.000 to say I have something that needs this amount of data, 889 00:49:40.880 --> 00:49:43.079 you know, and you can have multiples of those in 890 00:49:43.119 --> 00:49:46.679 whatever order you want, And inside of those responses you 891 00:49:46.760 --> 00:49:52.559 can have immediate, immediately returned partial parts of those responses 892 00:49:52.599 --> 00:49:55.280 and have some of them be delayed. So it's almost 893 00:49:55.360 --> 00:49:58.440 like you get the same experience inside of HTML where 894 00:49:58.480 --> 00:50:01.920 you can give the important stuff really quickly and delay 895 00:50:01.960 --> 00:50:04.960 the other stuff. You get that same capability within each 896 00:50:05.559 --> 00:50:07.360 request response life cycle. 897 00:50:07.880 --> 00:50:10.039 You can see it in this just just to say that. 898 00:50:10.119 --> 00:50:12.280 The joke that I like to say is that the 899 00:50:12.320 --> 00:50:16.280 big difference between old websites and modern websites is that 900 00:50:16.320 --> 00:50:19.039 we've replaced the single large spinner with a lot of 901 00:50:19.079 --> 00:50:20.199 small spinners. 902 00:50:21.480 --> 00:50:24.840 Yeah, we've been trying to solve that. 903 00:50:24.920 --> 00:50:25.159 I mean. 904 00:50:25.199 --> 00:50:28.199 The challenge is you can see in the shape that 905 00:50:28.320 --> 00:50:30.360 ht amount it self, it's x amount or you know, 906 00:50:30.400 --> 00:50:33.480 it's a markup language. So these things are naturally nested. 907 00:50:33.480 --> 00:50:34.960 You see it in your components. You have components and 908 00:50:34.960 --> 00:50:38.199 components and components and components. So like doing it top 909 00:50:38.239 --> 00:50:40.719 the bottom doesn't even work because the outer component hasn't closed, 910 00:50:40.760 --> 00:50:43.440 you know what I mean, like these envelopes. So what 911 00:50:43.599 --> 00:50:46.920 ends up happening is the trick to the h mell. 912 00:50:46.960 --> 00:50:50.880 Actually isn't that difficult mechanically because you can put it 913 00:50:50.920 --> 00:50:53.079 on the end in something invisible like a template, and 914 00:50:53.159 --> 00:50:57.199 have JavaScript move it back into place as it loads. 915 00:50:57.239 --> 00:50:59.519 The hard part is that is the data. If you 916 00:50:59.519 --> 00:51:02.039 actually want to wake up parts of that page before 917 00:51:02.079 --> 00:51:04.719 it all loads, you need to tell you need like 918 00:51:04.840 --> 00:51:08.159 a placeholder for the data. Essentially, you need to be like, look, 919 00:51:08.199 --> 00:51:10.440 this data will be coming or you know. 920 00:51:10.760 --> 00:51:14.800 And that's a promise and that's a problem or a substream. 921 00:51:15.280 --> 00:51:19.480 Right, So we started serializing well, I mean, and then 922 00:51:19.480 --> 00:51:22.199 there's different types of data right, like data objects, you know, 923 00:51:22.239 --> 00:51:25.639

and different things. So like even stuff like TRPC has 924 00:51:25.679 --> 00:51:29.000 like advanced like super JSON or like advanced data types 925 00:51:29.039 --> 00:51:31.920 you know. And but for us promises, we're the key 926 00:51:32.360 --> 00:51:35.639 for and we realized that we could bring that serialization 927 00:51:36.159 --> 00:51:38.519 not just in our original SSR, but use it in 928 00:51:38.599 --> 00:51:44.920 our server functions, so we could serialize anything, you know, HTML, elements, promises, whatever. 929 00:51:45.280 --> 00:51:48.760 And this meant that because both sides, RPC let both 930 00:51:48.760 --> 00:51:50.760 sides understand and this is in a sense like how 931 00:51:50.760 --> 00:51:53.559 server components work and React because they can go we 932 00:51:53.639 --> 00:51:57.400 have our special jsx on format and we can communicate 933 00:51:57.400 --> 00:51:59.639 both sides, and now we can communicate react components of 934 00:51:59.679 --> 00:52:02.039 the wire. As I said, our needs are a little 935 00:52:02.039 --> 00:52:05.119 bit simpler with like promises and streams, but it works 936 00:52:05.119 --> 00:52:08.199 out kind of similar. We it lets us build on 937 00:52:08.440 --> 00:52:12.159 really powerful capabilities on this because you can say, return 938 00:52:12.239 --> 00:52:15.280 some data with a promise encoded in it, and then 939 00:52:15.320 --> 00:52:17.119 like have the data come back in chunks. 940 00:52:17.119 --> 00:52:17.920 You can make an. 941 00:52:17.760 --> 00:52:20.679 ACYNC iterable and basically return the stream so the server 942 00:52:20.760 --> 00:52:23.719 can just keep on yielding data into your server function. 943 00:52:23.960 --> 00:52:26.639 And you write it literally as like an ACE generator function. 944 00:52:26.679 --> 00:52:28.960 So you write it as a like an acing function, 945 00:52:29.320 --> 00:52:33.519 and it'll our generator word yields and will literally be 946 00:52:33.599 --> 00:52:37.360 yielding from server to client. So there's a lot of 947 00:52:37.400 --> 00:52:39.440 really cool mechanics here. 948 00:52:39.639 --> 00:52:43.519 Do you support that in? I know that Quick supports that. 949 00:52:43.679 --> 00:52:46.000 I know that, or RBC supports that. Do you guys 950 00:52:46.000 --> 00:52:50.840 also support that that the ability to stream a response 951 00:52:50.920 --> 00:52:52.280 from ann RBC? 952 00:52:53.159 --> 00:52:56.480 Yeah, Salades, Yeah, it's in. It's in, Sarah Belle. I 953 00:52:56.480 --> 00:52:58.400 don't know if someone Start handles it the best in 954 00:52:58.400 --> 00:53:01.199 all cases, but the core technology support to it. 955 00:53:01.159 --> 00:53:06.679 So I guess side uh side quest here is we 956 00:53:06.679 --> 00:53:10.880 we and we started out building our own serializer I 957 00:53:10.920 --> 00:53:15.159 did for tansex Start that was had. It was a 958 00:53:15.199 --> 00:53:20.079 little bit lighter than something like sarahvel Or or the 959 00:53:20.119 --> 00:53:23.239 big giant serializer that that can do like re ex 960 00:53:23.280 --> 00:53:27.440 server components and stuff. And there's also super Jason there. 961 00:53:27.519 --> 00:53:29.960 There's even one that the remix team built right for 962 00:53:30.039 --> 00:53:30.760 react about. 963 00:53:30.880 --> 00:53:33.719 Somebody on the chat called it a tool boards. 964 00:53:33.079 --> 00:53:35.400 Cha Jason, Right, Yeah, there's there's a couple of these, 965 00:53:36.639 --> 00:53:39.239 and and I wrote a simple one that would kind 966 00:53:39.239 --> 00:53:43.039 of get to m v P for tansex Start Alpha. 967 00:53:43.159 --> 00:53:46.880 And even even the simple one could serialized promises and 968 00:53:46.960 --> 00:53:51.880 serialized streams. But then we we realized that we want 969 00:53:51.920 --> 00:53:56.039 to do more complex stuff. We've decided to adopt Sarahvell. 970 00:53:58.119 --> 00:54:02.239 I think I told you that, Ryan, right, okay for you. 971 00:54:03.199 --> 00:54:06.000 We so we have one that works for tansax start, 972 00:54:06.039 --> 00:54:11.199 but we're adopting Sarall because is beyond just being able 973 00:54:11.199 --> 00:54:13.880 to stream this stuff. Sarahville has some very unique So. 974 00:54:13.800 --> 00:54:16.519 What is Serville I think I missed explanation. 975 00:54:16.800 --> 00:54:20.440 It's it's the serializer used by SOLODJS use both in 976 00:54:20.480 --> 00:54:22.960 our server rendering and in our server functions. I was 977 00:54:22.960 --> 00:54:27.880 built by Alexis Monselek core team members sologs and yeah. 978 00:54:28.519 --> 00:54:33.599 It's basically serializes stuff over the wire and then de 979 00:54:33.719 --> 00:54:37.920 serialize it. But it's not exactly Jason. It's something else, 980 00:54:39.079 --> 00:54:42.239 like like React doesn't use Jason either. In case people 981 00:54:42.239 --> 00:54:42.719 don't know. 982 00:54:42.840 --> 00:54:43.519 For their. 983 00:54:44.800 --> 00:54:48.400 Responses from server from server components, you. 984 00:54:48.360 --> 00:54:50.199 See a lot of them that have like it's it's 985 00:54:50.239 --> 00:54:54.119 like a superset of Jason that they then encode and 986 00:54:54.159 --> 00:54:57.480 decode special characters, special things. 987 00:54:57.519 --> 00:55:00.320 Look for at the very least, you won't command lines 988 00:55:00.320 --> 00:55:02.760 separate the Jason in order to be able to send 989 00:55:02.800 --> 00:55:07.039 multiple messages and not be kind of stuck on on 990 00:55:07.159 --> 00:55:09.519 not closing the bracket or something. 991 00:55:10.679 --> 00:55:15.199 Is I think Saravel is very unique and really cool 992 00:55:15.239 --> 00:55:21.079 because Saravel does not Servell uses javascripts essentially to stream 993 00:55:21.320 --> 00:55:25.840 like to serialize all of this. Saravel uses JavaScript and 994 00:55:25.920 --> 00:55:28.519 streams

it and executes it over the wire, and it 995 00:55:28.639 --> 00:55:32.760 is it's incredible to watch it work. Because even beyond that, 996 00:55:32.840 --> 00:55:39.119 I mean super JC yeah, a little bit. Yes, I 997 00:55:39.119 --> 00:55:40.280 wouldn't want to call it that. 998 00:55:40.159 --> 00:55:41.800 But yeah, I mean there is a bit of that. 999 00:55:42.239 --> 00:55:45.880 And in some cases where the security isn't concerned, he's 1000 00:55:46.079 --> 00:55:49.519 he's been looking at alternate serialization formats so that you 1001 00:55:50.079 --> 00:55:54.760 don't have the evil aspect of it. But yeah, it is, 1002 00:55:54.760 --> 00:55:57.400 it is, there is there's. 1003 00:55:56.440 --> 00:55:58.599 Great power comes great responsibility. 1004 00:55:58.880 --> 00:56:01.360 But I mean the power is incredible because this is 1005 00:56:01.519 --> 00:56:05.360 this is what enables future facing patterns. We've never had 1006 00:56:05.480 --> 00:56:08.679 things like single page apps be able to easily do 1007 00:56:09.239 --> 00:56:13.559 basically picture. You know, people familiar with React query where 1008 00:56:13.599 --> 00:56:16.239 you can like do a mutation and invalidate like a 1009 00:56:16.239 --> 00:56:20.440 couple of queries. What if you can do the mutation 1010 00:56:21.159 --> 00:56:23.079 so send it to the server and have the server 1011 00:56:24.000 --> 00:56:27.280 figure out what the invalidate and then while it's still there. 1012 00:56:27.360 --> 00:56:30.159 Start fetching the data, that data on the server and 1013 00:56:30.199 --> 00:56:32.920 send it back, you know, like return right away from 1014 00:56:32.960 --> 00:56:35.920 your mutation, but then have it streaming back the data 1015 00:56:36.000 --> 00:56:37.760 for like the next page you're going to visit right. 1016 00:56:37.800 --> 00:56:39.280 If you have the knowledge of say like a router, 1017 00:56:39.719 --> 00:56:43.400 and you have this capability of serialization, you can do 1018 00:56:43.800 --> 00:56:45.760 like single flight mutations and stuff. 1019 00:56:45.960 --> 00:56:48.800 Crap is gonna restart because of not. 1020 00:56:48.719 --> 00:56:54.519 Just single mutations, but stream Yeah, for a minute or so, 1021 00:56:54.800 --> 00:57:01.719 I'll be back. It looks like, but you'll yeah, it's 1022 00:57:02.039 --> 00:57:04.320 not that it's single flight mutations doesn't been around forever, 1023 00:57:04.400 --> 00:57:07.519 but I mean that's how the web worked anyway. But 1024 00:57:08.800 --> 00:57:11.159 single flight mutations that are streamed, I think that's the 1025 00:57:11.159 --> 00:57:13.719 most important part of it. It's like as you get 1026 00:57:13.719 --> 00:57:15.719 the response, as you get the requests on the server, 1027 00:57:16.119 --> 00:57:18.800 and you start processing things that need to change, you 1028 00:57:19.039 --> 00:57:22.119 don't again, don't need to wait to know all of 1029 00:57:22.119 --> 00:57:23.920 the changes that are going to happen to send them 1030 00:57:23.920 --> 00:57:27.079 back to the client. You can start processing them and 1031 00:57:27.119 --> 00:57:31.800 shipping them as you find them to the client. That 1032 00:57:31.800 --> 00:57:36.599 that is incredible, so that you know you're in Validation 1033 00:57:36.800 --> 00:57:40.320 from the server can essentially be streamed in as soon 1034 00:57:40.400 --> 00:57:42.239 as you know about it to the client in the 1035 00:57:42.280 --> 00:57:43.039 same request. 1036 00:57:43.880 --> 00:57:46.480 The funny thing, though, is that that kind of goes 1037 00:57:46.559 --> 00:57:51.320 beyond RPC. That's more in the territory of SSR, isn't it. 1038 00:57:51.719 --> 00:57:56.880 No, Because we're still just talking about individual requests an 1039 00:57:57.000 --> 00:58:02.960 RPC for instance, to say, you know, I want to 1040 00:58:02.800 --> 00:58:05.599 go the base query maybe and then or say I 1041 00:58:05.639 --> 00:58:08.159 want to update a user. I want to update a 1042 00:58:08.280 --> 00:58:12.360 user capability. Right, I'm adding a capability to a user, 1043 00:58:12.840 --> 00:58:16.079 and you you go to add that capability on the 1044 00:58:16.119 --> 00:58:20.000 server side, You'll you'll receive that mutation, You'll you'll create 1045 00:58:20.039 --> 00:58:22.039 that mutation, and then you're probably going to have a 1046 00:58:22.079 --> 00:58:25.119 bunch of other things that need to be invalidated for 1047 00:58:25.199 --> 00:58:27.880 the user or refresh or streams to the user that 1048 00:58:27.920 --> 00:58:30.639 are going to be new. With that new capability, they'll 1049 00:58:30.639 --> 00:58:36.519 gain access to new items, new things, new collection types 1050 00:58:36.559 --> 00:58:40.679 inside of their application, and some of those items might 1051 00:58:40.679 --> 00:58:45.079 take longer for you to fetch on the server and 1052 00:58:45.119 --> 00:58:48.079 give to them than others, So out of the gate, 1053 00:58:48.519 --> 00:58:50.960 you'll want to ship them a new user object that'll 1054 00:58:50.960 --> 00:58:53.000 be really fast, So you ship that down in the 1055 00:58:53.039 --> 00:58:56.719 same response, you push that down, and then you're still 1056 00:58:56.760 --> 00:58:59.880 working on maybe maybe their team data or their work 1057 00:59:00.039 --> 00:59:02.519 based data, and then as you get those, you ship 1058 00:59:02.599 --> 00:59:06.039 those down as well, and so you can start in 1059 00:59:06.079 --> 00:59:10.360 the same request of just a mutation, the response can contain, 1060 00:59:10.840 --> 00:59:15.440 you know, immediate and streamed data. It's really interesting. 1061 00:59:16.079 --> 00:59:17.840 First of all, you're turning on a lot of light 1062 00:59:17.880 --> 00:59:21.400 bulbs for me, so thank you for that, and you're 1063 00:59:21.599 --> 00:59:25.920 raising and it's interesting because what I'm

thinking. I'm old 1064 00:59:26.039 --> 00:59:29.760 enough to remember the original RPC implementations back in the 1065 00:59:29.840 --> 00:59:33.880 nineties and one of the main problems with them was 1066 00:59:34.000 --> 00:59:40.840 the fact that they were built as being synchronous type operations, 1067 00:59:41.519 --> 00:59:45.360 and because the assumption was that it is kind of 1068 00:59:45.480 --> 00:59:50.199 like a function and function calls usually are cheap, so 1069 00:59:50.519 --> 00:59:53.320 you can make one function call for the fast stuff 1070 00:59:53.320 --> 00:59:56.039 and another function called for the for the slow stuff, 1071 00:59:56.159 --> 00:59:59.280 or get the call back or stuff like that, and 1072 00:59:59.679 --> 01:00:02.239 they did I didn't really accommodate for that scenario that 1073 01:00:02.280 --> 01:00:07.800 you're describing, where I'm requesting multiple data items and they 1074 01:00:07.840 --> 01:00:12.039 are available at different at different times, and that I 1075 01:00:12.199 --> 01:00:17.199 can create this kind of a sophisticated staggered response that 1076 01:00:17.599 --> 01:00:20.760 data arrives as soon as it's available, and I don't 1077 01:00:20.760 --> 01:00:23.639 need to make multiple calls in order to get all 1078 01:00:23.639 --> 01:00:27.480 this data. Yeah, I'm giving them mic back to you. 1079 01:00:28.760 --> 01:00:32.440 I think that it even goes He takes that even further. 1080 01:00:32.760 --> 01:00:34.880 Is yes, it works for data that you request you 1081 01:00:34.920 --> 01:00:37.320 may know about, but it also works for data that 1082 01:00:37.440 --> 01:00:40.320 maybe you don't want to know about but needs to 1083 01:00:40.360 --> 01:00:45.000 be sent. Is it leaves room now for this hidden 1084 01:00:45.440 --> 01:00:51.320 layer of meta data, of meta actions or meta code 1085 01:00:51.360 --> 01:00:54.119 that could happen with a request response. So, for example, 1086 01:00:54.840 --> 01:00:58.760 the developer experience that I would want as a developer 1087 01:00:58.960 --> 01:01:02.599 when I say update this user capability, I just want 1088 01:01:02.639 --> 01:01:06.719 to update that user capability. I don't want to I 1089 01:01:06.760 --> 01:01:10.360 don't want to have to be responsible for receiving and 1090 01:01:11.679 --> 01:01:14.360 acting on all of this extra data coming back to 1091 01:01:14.400 --> 01:01:16.280 me though. I just want to trust that it's going 1092 01:01:16.320 --> 01:01:18.400 to work. And so naturally, what do a lot of 1093 01:01:18.440 --> 01:01:19.960 people would say is that say, well, I'm going to 1094 01:01:20.039 --> 01:01:22.559 update this user with a new capability, and then they 1095 01:01:22.599 --> 01:01:25.199 get it back, and what do they expect. They expect 1096 01:01:25.360 --> 01:01:28.840 the response to be a user and the new version 1097 01:01:28.840 --> 01:01:32.239 of the user that has the updated capability. What they're 1098 01:01:32.280 --> 01:01:35.000 not going to expect is to have a bunch of 1099 01:01:35.119 --> 01:01:40.199 other random, you know, data invalidation payloads that they now 1100 01:01:40.239 --> 01:01:43.519 have to handle. So what's nice about something like Sarah 1101 01:01:43.559 --> 01:01:47.199 Bell is that it's it's not just you know, this 1102 01:01:47.440 --> 01:01:50.400 super set of Jason or whatever, but it's the ability 1103 01:01:50.480 --> 01:01:53.880 for even frameworks or middlewares or things in the middle 1104 01:01:53.920 --> 01:01:58.400 of that operation more code can just be sent down 1105 01:01:58.480 --> 01:02:01.800 to the client to execute that the response doesn't even 1106 01:02:01.840 --> 01:02:06.000 need to handle or know about. So it leaves a 1107 01:02:06.039 --> 01:02:10.960 lot of room for optimizations and frameworks to get into 1108 01:02:11.000 --> 01:02:14.519 this request response life cycle, but still keep the developer 1109 01:02:14.599 --> 01:02:17.519 developer experience really lean, not. 1110 01:02:17.599 --> 01:02:20.119 Meaning it means, but a little bit scary because if 1111 01:02:20.119 --> 01:02:23.599 I'm understanding correctly what you're saying is, let's say I 1112 01:02:23.679 --> 01:02:28.960 want to get the new user an updated user object 1113 01:02:29.000 --> 01:02:33.400 from the server. So I do an RPC call, I 1114 01:02:33.599 --> 01:02:36.519 get back the new user, and I do with it 1115 01:02:36.639 --> 01:02:39.239 whatever I do with it. But it turns out that 1116 01:02:39.760 --> 01:02:43.119 it also realized that some group that the user belongs 1117 01:02:43.159 --> 01:02:47.400 to updated, so it sends that down as well. I 1118 01:02:47.440 --> 01:02:51.159 don't handle it because I don't expect it, so I 1119 01:02:51.239 --> 01:02:53.559 didn't even write the code to handle it, but it 1120 01:02:53.679 --> 01:02:57.079 also sent the code that will handle it for me. 1121 01:02:57.280 --> 01:02:59.400 If I understand correctly, what you're kind. 1122 01:02:59.199 --> 01:03:02.480 Of it depends. It depends. A lot of this gets 1123 01:03:02.519 --> 01:03:07.159 into how you use such a tool, right, Yes, you 1124 01:03:07.239 --> 01:03:10.079 could stream down the code that handles it as well, 1125 01:03:10.119 --> 01:03:13.480 but more than likely that kind of code would live 1126 01:03:13.519 --> 01:03:16.000 on the client. It would live on the client side. 1127 01:03:16.599 --> 01:03:20.920 To say, we are orchestrating this metadata layer right as 1128 01:03:20.960 --> 01:03:23.719 the client. We know that we're going to want this 1129 01:03:23.840 --> 01:03:25.760 extra metadata to invalidate. 1130 01:03:25.880 --> 01:03:28.239 So it's a callback that I attached that one, or 1131 01:03:28.280 --> 01:03:31.679 middleware that I attach that gets invoked with the extra 1132 01:03:31.840 --> 01:03:36.039 data that happened to arrive on because of some other

1133 01:03:36.199 --> 01:03:37.880 call that caused it to be sent. 1134 01:03:38.159 --> 01:03:41.039 And we're talking about middleware that can span the client 1135 01:03:41.079 --> 01:03:43.440 and the server just like a server function. Right, it's 1136 01:03:43.480 --> 01:03:48.639 middleware that can compose together inside of this system that's 1137 01:03:48.719 --> 01:03:52.599 extracting into client and server and creating. It's RPC middleware 1138 01:03:52.880 --> 01:03:53.519 essentially what. 1139 01:03:53.480 --> 01:03:57.679 It is, correct, I'm trying to think of an actual 1140 01:03:57.960 --> 01:04:02.960 valid scenario and you tell me if it kind of matches. 1141 01:04:03.679 --> 01:04:07.280 So I know that a lot of times as secure 1142 01:04:07.320 --> 01:04:12.360 systems have this concept of a refresh token. So if 1143 01:04:12.440 --> 01:04:16.599 your access token in validates, you have a refresh stoken 1144 01:04:16.639 --> 01:04:19.559 that generates a new access token for you, and that 1145 01:04:19.760 --> 01:04:22.320 happens behind the scenes. You don't need to be aware 1146 01:04:22.360 --> 01:04:25.239 of this whole thing or this whole mechanism going on. 1147 01:04:25.360 --> 01:04:27.719 So is it something kind of like that. 1148 01:04:27.960 --> 01:04:30.480 I don't know if I would use this for that. 1149 01:04:31.360 --> 01:04:34.719 I mean you could, No, I'm just thinking about the 1150 01:04:34.840 --> 01:04:39.840 scenario where you're making a function call for a but 1151 01:04:40.000 --> 01:04:43.320 that triggers also other stuff to take place in the 1152 01:04:43.400 --> 01:04:46.679 system that you may not necessarily be aware of. 1153 01:04:47.000 --> 01:04:50.800 Yeah. I think what we're mostly talking about here is optimizations, right, 1154 01:04:50.920 --> 01:04:53.440 kind of like the example that Ryan brought up is 1155 01:04:53.440 --> 01:04:58.159 like you send off pre crashing. Yeah, you send off 1156 01:04:58.159 --> 01:05:01.440 a request with a mutation and the intent is known 1157 01:05:01.480 --> 01:05:04.440 that you're going to be at this destination next. Instead 1158 01:05:04.480 --> 01:05:08.440 of waiting for all of this to to settle, the 1159 01:05:08.519 --> 01:05:10.840 dust to settle before you go request the assets for 1160 01:05:10.920 --> 01:05:13.719 your next destination, you can do all of this in 1161 01:05:13.760 --> 01:05:17.039 one request. You can send all of the assets that 1162 01:05:17.079 --> 01:05:19.159 are going to be requested anyway. 1163 01:05:19.239 --> 01:05:21.559 Yeah, it's it's kind of interesting. 1164 01:05:21.199 --> 01:05:23.079 Kind of resource sense in a sense. 1165 01:05:23.920 --> 01:05:24.159 Yeah. 1166 01:05:24.320 --> 01:05:27.559 What I found kind of interesting about this resource. 1167 01:05:27.159 --> 01:05:29.000 Pushing resource pushing. 1168 01:05:29.079 --> 01:05:32.440 Yeah, when I when I was working on the solution, 1169 01:05:32.719 --> 01:05:35.079 was the kind of that realization is that people are 1170 01:05:35.079 --> 01:05:38.639 already writing their code mostly isomorphically, which means that like 1171 01:05:38.679 --> 01:05:42.800 they're already creating these patterns. So like running the say 1172 01:05:42.800 --> 01:05:46.920 the routeloaders again on the server and a mutation and 1173 01:05:47.000 --> 01:05:50.119 then expecting the code to be basically the same on 1174 01:05:50.199 --> 01:05:53.320 the client because it is the same code it's source 1175 01:05:53.400 --> 01:05:57.000 code basically gives you this ability. So like what was 1176 01:05:57.039 --> 01:05:59.960 kind of cool is yeah, the kind of optimization look 1177 01:06:00.079 --> 01:06:02.599 you can go in because if you're in a nested route, 1178 01:06:02.599 --> 01:06:04.519 if you're familiar with nest to routing, maybe the top 1179 01:06:04.559 --> 01:06:08.199 section doesn't change, only the like the two sections underneath 1180 01:06:08.280 --> 01:06:10.480 swap on this navigation, so you're like you're staying on 1181 01:06:10.480 --> 01:06:12.280 the same main page and then you go to the 1182 01:06:12.280 --> 01:06:14.840 next page. Well, if that data from the top main 1183 01:06:14.880 --> 01:06:17.559 page isn't being updated, then you don't have to fetch 1184 01:06:17.559 --> 01:06:20.480 it again on the server loaders. Like basically we were 1185 01:06:20.679 --> 01:06:24.519 able to use the same sort of knowledge of what 1186 01:06:24.679 --> 01:06:28.559 route changes and what data is already available based on 1187 01:06:29.039 --> 01:06:34.920 what things it would fetch when it navigates to those pages, 1188 01:06:35.480 --> 01:06:38.599 to the point that we basically go, Okay, this is 1189 01:06:38.639 --> 01:06:40.440 already there and the client don't need the updated and 1190 01:06:40.480 --> 01:06:43.440 it hasn't explicitly invalidated. This is already there, this is new, 1191 01:06:43.800 --> 01:06:46.880 this isn't just on this page, this has been updated. 1192 01:06:46.960 --> 01:06:50.679 And then fetch those things and put them on that request. 1193 01:06:50.760 --> 01:06:52.960 But the client are the server responds right away. So 1194 01:06:53.000 --> 01:06:55.320 the server goes, okay, we're going to redract to this 1195 01:06:55.400 --> 01:06:58.440 next page, and the client goes, okay, I'm going to 1196 01:06:58.480 --> 01:07:00.920 go to this next page. So the client goes to 1197 01:07:00.960 --> 01:07:04.280 that next page. But because those promise stubs are there, 1198 01:07:05.519 --> 01:07:07.400 when it goes to load the data, it goes, oh, no, 1199 01:07:07.480 --> 01:07:10.960 promise stub right here, it's already in the cash. I'm 1200 01:07:10.960 --> 01:07:13.360 going to use this promise instead of fetching it again 1201 01:07:14.119 --> 01:07:17.000 for the stuff that's new. So it's it's kind of 1202 01:07:17.719 --> 01:07:20.199 it's weird how you can

kind of like do this 1203 01:07:20.280 --> 01:07:23.239 kind of predictively, but in the end, what you end 1204 01:07:23.320 --> 01:07:25.199 up with, which is my favorite part about this, is 1205 01:07:25.559 --> 01:07:28.119 you're actually leveraging your knowledge of the client side cash 1206 01:07:28.119 --> 01:07:31.159 on the server here, so you actually don't need cashing 1207 01:07:31.280 --> 01:07:34.360 on the server in this mechanism. Like you could still 1208 01:07:34.400 --> 01:07:36.360 optimize it with like a rettis or something, but we 1209 01:07:36.760 --> 01:07:39.719 never went through that whole Next DS use cash dilemma 1210 01:07:40.039 --> 01:07:42.840 or cash stup because when you do server functions, you 1211 01:07:42.880 --> 01:07:44.519 re render the whole page. It's kind of like remix. 1212 01:07:44.559 --> 01:07:47.199 It's like that loader bit. You know the whole route sections. 1213 01:07:47.320 --> 01:07:49.239 So when you hit a you have five data points, well, 1214 01:07:49.239 --> 01:07:51.719 guess what, you are fetching all five data points. 1215 01:07:51.719 --> 01:07:54.920 There's no way for you to separate those apart. 1216 01:07:54.679 --> 01:07:56.280 Which means that if you don't want to refetch all 1217 01:07:56.320 --> 01:07:58.679 five data points every single time, you are going to 1218 01:07:58.719 --> 01:08:01.320 cash them on the server. This approach you'll let you 1219 01:08:01.400 --> 01:08:04.559 basically use the knowledge of the route and the knowledge 1220 01:08:04.559 --> 01:08:07.840 of the invalidation from the mutation to actually only fetch 1221 01:08:07.840 --> 01:08:11.159 what's needed, so server cashes aren't necessary. It feels like 1222 01:08:11.159 --> 01:08:12.760 a single page app word. You know, the cache is 1223 01:08:12.840 --> 01:08:15.960 on the client, but it's actually doing this all in 1224 01:08:15.960 --> 01:08:16.680 a single. 1225 01:08:16.880 --> 01:08:20.199 So again, let me see if I'm getting this, because 1226 01:08:21.079 --> 01:08:23.560 to an extent, it's kind of incidental to the fact 1227 01:08:23.560 --> 01:08:27.680 that it's RPC. It's basically the fact that you're controlling 1228 01:08:28.439 --> 01:08:31.479 both sides and the protocol that lets you do a 1229 01:08:31.520 --> 01:08:34.239 lot of magic. The fact that it's RPC, like I said, 1230 01:08:34.239 --> 01:08:38.439 it's almost incidental. It might have been some other mechanism. 1231 01:08:39.279 --> 01:08:40.720 But what you're. 1232 01:08:40.640 --> 01:08:44.880 Saying is this, I'm triggering an operation to receive data. 1233 01:08:45.920 --> 01:08:59.159 I know that this operation will likely trigger redirection or 1234 01:08:59.479 --> 01:09:06.600 transition to another page. I can prefetch or push more accurately. 1235 01:09:06.680 --> 01:09:09.920 I can like you said tenor I use the wrong analogy, 1236 01:09:09.960 --> 01:09:13.359 because it's not client instigated, its server instigated. The server 1237 01:09:13.560 --> 01:09:18.039 side knows that I'm likely going to be needing that 1238 01:09:18.159 --> 01:09:23.479 additional data. I can send it down, hold it somewhere 1239 01:09:23.479 --> 01:09:27.039 in the client side so that when I actually needed 1240 01:09:27.159 --> 01:09:28.119 it's already there. 1241 01:09:28.760 --> 01:09:33.640 Basically, and that becomes even more powerful as you stream, 1242 01:09:34.399 --> 01:09:37.680 because we could do this before with single flight mutation. 1243 01:09:37.800 --> 01:09:41.079 As you send it, and if you spend enough time 1244 01:09:41.119 --> 01:09:43.560 on the server, you can gather up all of the 1245 01:09:43.640 --> 01:09:46.840 data and finally send it all back and then allow 1246 01:09:46.880 --> 01:09:51.920 the user to navigate. But streaming allows you to respond immediately, 1247 01:09:52.640 --> 01:09:57.039 but tick off those requests server side and then stream 1248 01:09:57.079 --> 01:10:01.840 them down to the user and utilize utilize that connection 1249 01:10:01.920 --> 01:10:02.800 that's already open. 1250 01:10:02.920 --> 01:10:06.439 It's because the frameworks support a signatively. Things like suspense 1251 01:10:07.119 --> 01:10:10.479 basically will trigger and treat your cached promise or your 1252 01:10:10.720 --> 01:10:13.720 pre pushed promise, and a new promise would fetch identically. 1253 01:10:14.119 --> 01:10:17.880 So in these kind of scenarios, you actually get further ahead. 1254 01:10:18.000 --> 01:10:20.760 You can start rendering the next page before that data 1255 01:10:20.920 --> 01:10:21.560 has arrived. 1256 01:10:22.960 --> 01:10:26.319 And the fact that we're componentized kind of necessitates this 1257 01:10:26.399 --> 01:10:29.640 whole thing because otherwise one of the big problems with 1258 01:10:30.159 --> 01:10:35.439 components is that in capsulation, if you're following through on 1259 01:10:35.479 --> 01:10:41.479 it often leads to waterfalls. So the fact and react 1260 01:10:41.520 --> 01:10:44.560 query it back of the day at the time was 1261 01:10:44.840 --> 01:10:49.439 so great in this regard because you fetched from one 1262 01:10:49.479 --> 01:10:52.920 component and then it got reused the data in other 1263 01:10:53.000 --> 01:10:59.039 components without you needing to like break in capsulation be 1264 01:10:59.279 --> 01:11:03.000 very iplicit about it. It was totally implicit. So now 1265 01:11:03.000 --> 01:11:05.520 you're kind of taking it to the next level in 1266 01:11:05.560 --> 01:11:07.720 a sense this and this. 1267 01:11:08.000 --> 01:11:10.439 Opens up new can of worms. I don't know how 1268 01:11:10.439 --> 01:11:12.720 deeply you want to get into that, but components have 1269 01:11:12.800 --> 01:11:17.399 you on again component level data fetching it. I'm still 1270 01:11:18.319 --> 01:11:21.640 I think it's still really the way to go. And 1271 01:11:21.680 --> 01:11:27.199 then

thinking about thinking about the the optimizations that need 1272 01:11:27.279 --> 01:11:30.800 to be made at the routing level and the SEO 1273 01:11:30.960 --> 01:11:33.479 level and the page levels to get rid of waterfalls, 1274 01:11:33.479 --> 01:11:36.880 and that you know these are optimizations and making those 1275 01:11:36.880 --> 01:11:41.359 optimizations as easy as we can is really important, and 1276 01:11:41.439 --> 01:11:45.159 we can do that through API design with our routing. 1277 01:11:45.359 --> 01:11:48.960 We could do it through compilers like relay, but they 1278 01:11:49.039 --> 01:11:52.760 are optimizations. I think at that point, I like this, 1279 01:11:53.279 --> 01:11:55.039 I like everything that we've talked about is really. 1280 01:11:55.119 --> 01:11:57.439 I interrupt you again because I have to say that 1281 01:11:57.600 --> 01:12:00.760 one of the biggest downfalls of RP see back in 1282 01:12:00.800 --> 01:12:03.760 the old days, and one that I was so concerned 1283 01:12:03.800 --> 01:12:06.760 with that I actually at the end of my presentation 1284 01:12:06.920 --> 01:12:10.319 or RPC, I talk about the potential downsides of RPC, 1285 01:12:10.439 --> 01:12:13.520 and it's one of the items listed there is the 1286 01:12:13.560 --> 01:12:20.000 fact that RPC kind of encourages waterfalls because you make 1287 01:12:20.039 --> 01:12:22.760 a function call to get some data, and then you 1288 01:12:22.840 --> 01:12:25.880 make another function call to get some more data, and 1289 01:12:25.960 --> 01:12:28.520 another function called to get some more data, so you 1290 01:12:28.640 --> 01:12:34.319 end up with chatty protocols and waterfalls because the implicit 1291 01:12:34.359 --> 01:12:37.479 assumption is that it works like functions and functions are cheap. 1292 01:12:38.479 --> 01:12:43.199 And what you're saying is that you're overcoming it by 1293 01:12:43.439 --> 01:12:47.359 being smart realizing you know, you can still write it 1294 01:12:47.039 --> 01:12:51.800 like it is if it's a waterfall, but you've triggered 1295 01:12:51.840 --> 01:12:55.039 the requests, the generation of the code that's going to 1296 01:12:55.079 --> 01:12:58.399 be requested in the third request, in the first request, 1297 01:12:58.600 --> 01:13:02.439 and already be even scented down, so by the time 1298 01:13:02.520 --> 01:13:06.479 I get to that third RPC call, it's returning immediately 1299 01:13:06.600 --> 01:13:08.359 because all the data is already there. 1300 01:13:08.520 --> 01:13:12.800 Yeah, we're getting into what I would call orchestration of 1301 01:13:12.880 --> 01:13:17.600 our PC, like RPC orchestration because and I think that 1302 01:13:18.399 --> 01:13:21.640 you know, single flight mutations is one kind of flavor 1303 01:13:22.119 --> 01:13:25.920 of utilizing rpcs and orchestrating like data flow through rpcs. 1304 01:13:26.279 --> 01:13:31.760 There's other ones like routing is a big RPC orchestrator

really, 1305 01:13:31.760 --> 01:13:35.039 anything that's providing life cycle based on user input, so 1306 01:13:35.359 --> 01:13:37.520 even forms or the framework itself. 1307 01:13:37.520 --> 01:13:43.880 It's it's tricky because the biggest cause of waterfalls, in 1308 01:13:43.920 --> 01:13:48.840 my opinion, in terms of co location is often those 1309 01:13:48.880 --> 01:13:52.119 two causes. There's the code splitting. We want to code 1310 01:13:52.159 --> 01:13:54.920 split at the route level generally, like you know, you 1311 01:13:54.920 --> 01:13:57.520 can do lazy components wherever, but because of the code splitting, 1312 01:13:58.279 --> 01:14:01.000 it's hard to fetch the day before you have the 1313 01:14:01.039 --> 01:14:04.439 code to pitch the data essentially, So that's what pushes 1314 01:14:04.479 --> 01:14:07.239 us to hoisting. And it's necessary because you don't want 1315 01:14:07.239 --> 01:14:08.600 to load all the JABSKO for your whole app. 1316 01:14:08.640 --> 01:14:11.960 But if you didn't, if. 1317 01:14:11.840 --> 01:14:16.199 You didn't actually do that, then the other second thing 1318 01:14:16.239 --> 01:14:20.039 you hit on the client. Is that co location of 1319 01:14:20.159 --> 01:14:24.000 UI and components can lead to waterfalls depending on how 1320 01:14:24.079 --> 01:14:27.560 the renderer handles the ACYNC in the in the rendering. 1321 01:14:27.680 --> 01:14:30.439 So like, for example, let's say every time you hit 1322 01:14:30.479 --> 01:14:32.880 a promise, you throw and it then re renders the 1323 01:14:32.880 --> 01:14:35.039 whole thing. Well, if there's a promise after that, well 1324 01:14:35.399 --> 01:14:37.199 then you're causing a waterfall, right. 1325 01:14:37.119 --> 01:14:40.560 And I'm saying that because RPC potentially brings in the 1326 01:14:40.640 --> 01:14:44.680 third cause, which is just the fact that people can 1327 01:14:45.239 --> 01:14:48.119 look at the code think that if it looks like 1328 01:14:48.199 --> 01:14:51.279 a function, then it is a function, and just write 1329 01:14:51.279 --> 01:14:54.800 the code in a way that's very inefficient and generates 1330 01:14:54.800 --> 01:14:57.479 a waterfall regardless of the framework. 1331 01:14:57.520 --> 01:15:00.239 Right right, which is which is well, I mean there's 1332 01:15:00.239 --> 01:15:04.239 two different types of waterfalls, necessary waterfalls and unnecessari stary waterfalls. 1333 01:15:04.239 --> 01:15:08.239 Necessary waterfalls can still be made unnecessary if you say, 1334 01:15:08.359 --> 01:15:10.239 move everything into a single function call and you know, 1335 01:15:10.319 --> 01:15:11.319 put them together whatever. 1336 01:15:11.560 --> 01:15:13.119 But there's a dependency. 1337 01:15:13.199 --> 01:15:15.840 But there's a dependency, right, Like there's like you need 1338 01:15:15.880 --> 01:15:18.600 to get the users to get or get the user 1339 01:15:18.640 --> 01:15:20.399 to get the posts for some reason. But if you 1340 01:15:20.399 --> 01:15:22.479 could fetch them both off the user ID, like the 1341 01:15:22.520 --> 01:15:24.640 poster is user ID and the user information off use ID, 1342 01:15:24.760 --> 01:15:27.399 then that's an unnecessary waterfall. The problem is we cause 1343 01:15:27.479 --> 01:15:31.960 unnecessary waterfalls all the time in our UI rendering. If 1344 01:15:32.079 --> 01:15:35.159 if because we go okay, well the posts go under 1345 01:15:35.199 --> 01:15:39.319 the user section, and then you you basically by by 1346 01:15:39.520 --> 01:15:41.479 using ACYNC in your component, you're basically like putting in 1347 01:15:41.479 --> 01:15:44.039 a weight in the middle and blocking. Blocking rendering sucks 1348 01:15:44.039 --> 01:15:48.399 a weights suck for rendering UI. You don't want ACYNC 1349 01:15:48.399 --> 01:15:51.880 components really it React gets away with it on the 1350 01:15:51.880 --> 01:15:54.640 server because it's on the server, and server waterfalls are 1351 01:15:54.680 --> 01:15:55.479 not as bad. 1352 01:15:55.520 --> 01:15:56.880 But I'd argue against that. 1353 01:15:56.920 --> 01:16:00.159 I'm generally speaking it's this co location of data and 1354 01:16:00.319 --> 01:16:04.199 UI that causes this blocking. The reason I'm stressing on 1355 01:16:04.239 --> 01:16:08.760 this is because it's solvable with signals, Like basically, if 1356 01:16:08.840 --> 01:16:11.880 you're doing fine green rendering, there's no reason to await 1357 01:16:12.079 --> 01:16:14.439 or block except for where the data is finally being 1358 01:16:14.520 --> 01:16:16.960 used at the end of the data chain, which means 1359 01:16:16.960 --> 01:16:21.399 that you could parallelize this data fetching for unnecessary waterfalls 1360 01:16:21.680 --> 01:16:27.479 not only for like sibling components, but also nested components. 1361 01:16:27.520 --> 01:16:30.720 Because the component aspect doesn't matter, you're not blocking to 1362 01:16:30.760 --> 01:16:34.960 re render the the you know this component, you're literally 1363 01:16:35.079 --> 01:16:37.279 just going, oh, I actually need this in this text, 1364 01:16:37.279 --> 01:16:40.800 in this div I'm going to block there and everything beside. 1365 01:16:40.840 --> 01:16:44.079 It's a sibling. You basically turn all you flatten the 1366 01:16:44.079 --> 01:16:44.600 whole tree. 1367 01:16:44.760 --> 01:16:46.640 And this is something you know, just to be clear, 1368 01:16:47.000 --> 01:16:51.880 just you do all this magic for us automatically, right, 1369 01:16:52.159 --> 01:16:53.439 It's not something. 1370 01:16:53.880 --> 01:16:56.920 I mean, this is run to time what I'm talking about. 1371 01:16:56.960 --> 01:16:58.640 The funniest thing is it's not actually magic. It's just 1372 01:16:58.680 --> 01:17:02.119 the way signals work. This is something that I kind 1373 01:17:02.159 --> 01:17:03.800 of discovered a while ago when I was doing fine 1374

01:17:03.800 --> 01:17:08.760 green rendering. That pine green rendering is actually it flattens 1375 01:17:08.760 --> 01:17:11.199 the tree. That basically what does there's no components anymore. 1376 01:17:11.239 --> 01:17:13.520 You just have a bunch of independent things. So if 1377 01:17:13.520 --> 01:17:14.119 you fly on the. 1378 01:17:14.039 --> 01:17:18.479 Tree, because signals don't care about component boundaries essentially. 1379 01:17:18.039 --> 01:17:20.039 So if you fly in the tree and talk about 1380 01:17:20.279 --> 01:17:23.479 async that way, then it's the same thing. Nothing has 1381 01:17:23.520 --> 01:17:26.119 to block unless it actually has a data dependency on itself. 1382 01:17:26.159 --> 01:17:30.199 So necessary waterfalls still walk, but things that are not 1383 01:17:30.279 --> 01:17:33.479 necessary waterfalls don't need to block. So I think this 1384 01:17:33.640 --> 01:17:36.560 is another wind that you're going to see in the 1385 01:17:36.560 --> 01:17:39.600 signal of libraries. So people haven't really been leveraging this yet, 1386 01:17:39.760 --> 01:17:43.359 but it's coming soon and we know what it looks like. 1387 01:17:43.600 --> 01:17:45.039 Right, So I'm going to jump in here because we're 1388 01:17:45.079 --> 01:17:47.800 running a little long here on time, and I have 1389 01:17:47.840 --> 01:17:50.239 a suspicion with anything that Dan gets into. We could 1390 01:17:50.239 --> 01:17:53.760 talk to for two or three hours when he gets 1391 01:17:53.800 --> 01:17:56.520 into a topic. So before we wrap up and head 1392 01:17:56.520 --> 01:18:01.399 to picks, is there any last word on our PCs? 1393 01:18:01.800 --> 01:18:02.279 In summary? 1394 01:18:02.319 --> 01:18:04.800 And all I can say is my summary is that 1395 01:18:04.840 --> 01:18:08.439 we absolutely positively need to get Ryan and Tanner on 1396 01:18:08.720 --> 01:18:12.000 to continue this conversation because we are scratching the surface. 1397 01:18:12.039 --> 01:18:12.720 It feels to me. 1398 01:18:12.920 --> 01:18:15.960 Yeah, I mean, even just what Ryan brought up about, 1399 01:18:16.000 --> 01:18:20.920 like all the ACYNC signal stuff, there's a lot that 1400 01:18:20.960 --> 01:18:21.600 we could go into. 1401 01:18:21.680 --> 01:18:24.199 Yeah, but then stuck is built on react. What does 1402 01:18:24.239 --> 01:18:25.960 that have to do with the sink signals? 1403 01:18:26.359 --> 01:18:28.439 Maybe you say something about that, let's say, let's say 1404 01:18:28.479 --> 01:18:31.600 it for later, Let's save that for later. We are 1405 01:18:31.680 --> 01:18:35.119 running along. There's a lot to talk about. But and 1406 01:18:35.199 --> 01:18:37.279 you know, hold on, you brought up a good point 1407 01:18:37.279 --> 01:18:43.800 though about the necessary waterfalls as well, Like necessary waterfalls 1408 01:18:43.800 --> 01:18:45.720 are still there and they still need to be handled, 1409 01:18:46.199 --> 01:18:48.560 And like

I feel like I've been spending a lot 1410 01:18:48.560 --> 01:18:51.159 of time on that as well as like, you can 1411 01:18:51.199 --> 01:18:54.840 still make mistakes there that you can't solve with a 1412 01:18:54.880 --> 01:18:57.760 bundler or you can't solve with with signals or anything 1413 01:18:57.760 --> 01:19:00.239 like that. So but you can solve some of those 1414 01:19:00.239 --> 01:19:04.680 problems with with good API design and prefetching and and 1415 01:19:04.720 --> 01:19:06.840 you know, so, I think there's a lot more to 1416 01:19:06.960 --> 01:19:11.119 unpack there. I don't really want to. Okay, there's a 1417 01:19:11.159 --> 01:19:16.600 reason that tan Stack everything is built to be agnostic. 1418 01:19:17.119 --> 01:19:20.359 I'm a very firm believer and React and obviously it's 1419 01:19:20.399 --> 01:19:24.600 it's our most supportive framework, but it by no means perfect. 1420 01:19:24.760 --> 01:19:29.159 It's it's not, it's but it's amazing, it's great. There 1421 01:19:29.319 --> 01:19:32.800 there's pros and cons to every UI framework, but I 1422 01:19:33.119 --> 01:19:38.560 I'm very much preparing for a future where there are bigger, 1423 01:19:38.720 --> 01:19:44.520 better UI frameworks doing amazing things. And the things that 1424 01:19:44.680 --> 01:19:48.319 Ryan just teased and talking about with like signals and 1425 01:19:48.399 --> 01:19:53.479 acinc and flattening signals to to you know, around suspense 1426 01:19:53.560 --> 01:19:58.520 and things like that, that stuff's really exciting. Uh I. 1427 01:19:58.560 --> 01:20:00.399 And I'm just gonna gush a little bit right here 1428 01:20:00.439 --> 01:20:03.359 before we end and say that the things that Ryan 1429 01:20:03.600 --> 01:20:06.840 is working on with solid two point zero have made 1430 01:20:06.840 --> 01:20:10.439 me the most excited about what's technically possible with the 1431 01:20:10.560 --> 01:20:15.880 UI framework since I discovered React and discovered hooks and 1432 01:20:16.359 --> 01:20:19.079 really got into it. So hopefully it's a good teaser 1433 01:20:19.159 --> 01:20:21.000 for maybe what we can talk about next time. 1434 01:20:21.119 --> 01:20:25.920 Thank you, look, I'm here for it each and every 1435 01:20:25.920 --> 01:20:28.279 time you just say when I'll have you on the 1436 01:20:28.319 --> 01:20:28.840 show again. 1437 01:20:29.000 --> 01:20:32.760 Alrighty well, thanks to Ryan and Tanner for scratching the 1438 01:20:32.760 --> 01:20:37.479 surface on our PCs and waiting our whistle for more 1439 01:20:37.479 --> 01:20:40.199 discussion on the truly geeky stuff that we talk about. 1440 01:20:41.399 --> 01:20:43.399 With that, we'll move to picks picture, the part of 1441 01:20:43.439 --> 01:20:45.800 the show where we get to talk about anything we 1442 01:20:45.840 --> 01:20:47.840 want to talk about, could be tech related, could be 1443 01:20:47.880 --> 01:20:52.880 not tech related. We run the gamut. I will

start 1444 01:20:52.880 --> 01:20:55.439 off with what I consider the high point of any 1445 01:20:55.439 --> 01:20:57.640 of our episodes, which is the dad jokes of the week. 1446 01:20:58.800 --> 01:21:00.960 So the other day I was watching a show called 1447 01:21:01.000 --> 01:21:03.760 ten Ways to Avoid a Shark attack, and I was 1448 01:21:03.800 --> 01:21:06.359 surprised that stay out of the water wasn't on the list. 1449 01:21:06.520 --> 01:21:11.279 There was actually a skit about that on YouTube where 1450 01:21:11.680 --> 01:21:15.279 they do a parody of a horror movie when there's 1451 01:21:15.359 --> 01:21:18.399 the shark in the pool, and everybody's like, oh my god, 1452 01:21:18.439 --> 01:21:19.560 there's a shark in the pool. 1453 01:21:19.600 --> 01:21:20.359 What can we do in this? 1454 01:21:20.479 --> 01:21:22.239 The one guy keeps on saying. 1455 01:21:22.479 --> 01:21:25.359 Just don't go into the pool, right right. 1456 01:21:25.439 --> 01:21:29.880 So yeah, my drum joke here is not working. And 1457 01:21:29.920 --> 01:21:32.600 I'm really bummed because that adds all the impact. So 1458 01:21:32.760 --> 01:21:35.760 I'm gonna have to sue a riverside for that one. 1459 01:21:36.319 --> 01:21:39.640 So my wife looked at my feet this morning and said, honey, 1460 01:21:39.640 --> 01:21:41.720 your socks don't match. And I said, that's funny. I 1461 01:21:41.720 --> 01:21:43.399 have another pair just like them in the drawer. But 1462 01:21:43.520 --> 01:21:47.760 it boom. And then finally, in a surprising announcement, Head 1463 01:21:47.800 --> 01:21:52.279 Shoulders have decided to discontinue their popular anti dandruff shampoo line. 1464 01:21:52.359 --> 01:21:55.359 The decision left many people scratching their heads. I expected 1465 01:21:55.840 --> 01:21:57.880 not that I need that, as you can tell by 1466 01:21:57.920 --> 01:22:01.159 the video. So those are the dad jokes of the week. Dan, 1467 01:22:01.399 --> 01:22:02.600 you got any picks for us? 1468 01:22:03.079 --> 01:22:05.479 Yeah? So two funny things. 1469 01:22:06.000 --> 01:22:08.920 First of all, Avishai Shalom, we've had on this show 1470 01:22:09.079 --> 01:22:13.039 a while back, made an interesting observation on X and 1471 01:22:13.079 --> 01:22:15.920 I literally quote him because he just wrote it very well. 1472 01:22:16.319 --> 01:22:19.720 He was talking about the fact that will Ai destroy 1473 01:22:19.800 --> 01:22:24.960 the Worldwide Web because the bit it's destroying the web's 1474 01:22:25.039 --> 01:22:29.399 business model, and he says it's actually worse. NLM's marked 1475 01:22:29.399 --> 01:22:32.720 the end of open networks because the cost of producing 1476 01:22:32.880 --> 01:22:37.399 junk and malicious content is now near zero. We already 1477 01:22:37.479 --> 01:22:41.239 see this in LinkedIn, Facebook, et cetera, but more alarming 1478 01:22:41.359 --> 01:22:46.239 in GitHub and NPM. And it's a very interesting observation,

1479 01:22:46.359 --> 01:22:49.680 I think, And so that would be my first pick, 1480 01:22:49.720 --> 01:22:52.680 that observation. And the second one is this funny story 1481 01:22:52.680 --> 01:22:56.039 that just came out about the fact that the UK 1482 01:22:56.239 --> 01:22:59.840 government is trying to sue four Chan. Turns out that 1483 01:22:59.880 --> 01:23:04.079 the the UK passed the law that requires age verification 1484 01:23:04.760 --> 01:23:11.000 before you access potentially offensive content, and four Chan, being 1485 01:23:11.039 --> 01:23:16.000 an American company, is not complying with the UK laws, 1486 01:23:16.319 --> 01:23:21.279 so they're actually trying to force them to comply by 1487 01:23:21.520 --> 01:23:26.039 they sent them a threatening email and they basically responded 1488 01:23:26.159 --> 01:23:30.359 with First Amendment bitches. And it will be interesting to 1489 01:23:30.399 --> 01:23:32.880 see where this goes. So yeah, that would be my 1490 01:23:33.000 --> 01:23:38.039 second pick. And I think you can tell which side 1491 01:23:38.079 --> 01:23:41.760 them on in this argument, or put it this way, 1492 01:23:41.920 --> 01:23:44.479 The worst thing that has ever ever happened to the web, 1493 01:23:44.520 --> 01:23:46.399 I think is GDPR. 1494 01:23:46.960 --> 01:23:47.359 Yes, and. 1495 01:23:50.079 --> 01:23:51.600 Yeah, we don't need any more of that. 1496 01:23:52.439 --> 01:23:55.600 So yeah, those would be my two picks for today. 1497 01:23:55.720 --> 01:23:57.720 All right, Tanner, you got any picks for us? 1498 01:23:57.920 --> 01:24:01.800 Picks? Picks them of these pics? Do these picks needed? 1499 01:24:02.039 --> 01:24:06.640 Is random the room? The randomer the better, randomer the better. 1500 01:24:07.000 --> 01:24:09.880 Okay, why you think about it, We'll go to Ryan. 1501 01:24:09.960 --> 01:24:11.079 See if Ryan anything. 1502 01:24:11.960 --> 01:24:14.880 Ryan, I'm just gonna think here because I've been so busy. 1503 01:24:15.039 --> 01:24:17.279 If you guys don't know, I have a little baby 1504 01:24:17.439 --> 01:24:20.760 at home, so I have that to your pick. Yeah, 1505 01:24:20.800 --> 01:24:24.119 I mean, I mean, honestly, I don't get to watch 1506 01:24:24.199 --> 01:24:26.199 or check out nearly as much as I want to 1507 01:24:26.479 --> 01:24:28.920 that and like kids shows. I recently watched what it 1508 01:24:28.960 --> 01:24:30.600 was like K Pop Demon Hunters. 1509 01:24:31.319 --> 01:24:32.920 I've heard real good things about that one. 1510 01:24:32.960 --> 01:24:35.479 Yeah, you know, I mean if I mean, people are 1511 01:24:35.479 --> 01:24:38.000 gonna disagree with me, but it gave me like it's 1512 01:24:38.039 --> 01:24:42.279 got almost like Sailor Moon vibes, but like some big production, 1513 01:24:43.720 --> 01:24:45.159 you know, thang it. 1514 01:24:45.159 --> 01:24:46.640 It was fun, the kids liked it. 1515 01:24:47.600 --> 01:24:49.920 Since you mentioned the show, and to give Tennor a 1516 01:24:50.000 --> 01:24:52.119 little bit more time, I have to say that I 1517 01:24:52.319 --> 01:24:57.000 was really disappointed with the second season of San I mean, 1518 01:24:57.199 --> 01:25:00.920 they had an entire episode which was literally funeral. I 1519 01:25:00.960 --> 01:25:02.560 mean what the half. 1520 01:25:02.640 --> 01:25:05.159 I haven't watched that one, so I can't. 1521 01:25:05.640 --> 01:25:07.359 Oh, I know, I know what else I want to 1522 01:25:07.359 --> 01:25:09.319 say without giving away too much. I actually enjoyed the 1523 01:25:09.399 --> 01:25:11.960 ending of season three of Squid game station to have 1524 01:25:12.000 --> 01:25:15.359 split it, but oh really, but I like the second 1525 01:25:15.399 --> 01:25:18.479 third season together. It ended in a I like the 1526 01:25:18.479 --> 01:25:20.800 way it ended, So maybe I'm made me minority. But 1527 01:25:20.840 --> 01:25:23.560 I actually if if if you're willing to watch the 1528 01:25:23.600 --> 01:25:26.000 second season, that you should finish it with the third season. 1529 01:25:26.279 --> 01:25:28.479 Well, yeah, is really into that one, and he was 1530 01:25:28.520 --> 01:25:30.359 explaining the plot to me. I haven't watched the NAVA, 1531 01:25:30.399 --> 01:25:32.640 but he's explaining to me, and I mean, it sounded 1532 01:25:33.039 --> 01:25:35.079 the first season is just creeped me out. It was 1533 01:25:35.119 --> 01:25:36.880 more of a Hunger Games type vibe and it just 1534 01:25:37.000 --> 01:25:39.720 sort of creeped me out. But he was explaining what 1535 01:25:39.880 --> 01:25:41.720 was going on in the second third seasons to me, 1536 01:25:41.800 --> 01:25:44.279 and that's that's pretty intriguing the way they're doing it 1537 01:25:44.680 --> 01:25:45.000 right now. 1538 01:25:45.119 --> 01:25:46.880 Thank you word for it, as long as you don't 1539 01:25:46.880 --> 01:25:49.479 tell me that you enjoyed the eighth season of Game 1540 01:25:49.479 --> 01:25:50.039 of Thrones. 1541 01:25:52.000 --> 01:25:54.640 No, no, that was that was not my favorite. All right, Tanner, 1542 01:25:54.680 --> 01:25:55.439 we gave you some time. 1543 01:25:55.479 --> 01:25:58.119 What do you got. I mean, I like Ryan I, 1544 01:25:58.199 --> 01:26:02.760 so I don't consume a whole lot of of what's 1545 01:26:02.800 --> 01:26:06.920 out there. I'm I'm more of a builder, but there 1546 01:26:07.159 --> 01:26:09.520 there are a few things that I do I do enjoy. 1547 01:26:09.600 --> 01:26:14.359 So I'm overly hyped for the new season of Stranger 1548 01:26:14.399 --> 01:26:17.800 Things coming out, and so we've been rewatching all of 1549 01:26:17.840 --> 01:26:20.279 the seasons before it. So that means that I've seen 1550 01:26:20.279 --> 01:26:23.479 the fourth the first season four times, the second season 1551 01:26:23.520 --> 01:26:27.239 three one, and so forth, and we're watching the fourth 1552 01:26:27.279 -->

01:26:29.800 season four the second time now, and then we're going 1553 01:26:29.840 --> 01:26:31.840 to anxiously await number five. Yeah. 1554 01:26:32.079 --> 01:26:35.359 That's an interesting argument that I had with aj about 1555 01:26:36.920 --> 01:26:41.199 fantasy book series that tend to come, you know, not 1556 01:26:41.279 --> 01:26:44.600 yet finished, and then the next book comes three years 1557 01:26:44.640 --> 01:26:47.560 after the previous book, and you don't remember anything. And 1558 01:26:47.640 --> 01:26:50.520 I never have it in me to reread that those 1559 01:26:50.600 --> 01:26:53.640 previous books. So you're basically you do have it in 1560 01:26:53.680 --> 01:26:55.399 you to rewatch the entire series. 1561 01:26:55.439 --> 01:26:58.800 They were they were so good, and you know, Stranger 1562 01:26:58.880 --> 01:27:03.479 Things connoisseurs will tell you, well, this season was worse 1563 01:27:03.520 --> 01:27:07.399 and this season was terrible, and but like going back 1564 01:27:07.439 --> 01:27:10.439 and watching them, I mean, I'm it's been a long 1565 01:27:10.439 --> 01:27:12.600 time since the first one came out, so like, I 1566 01:27:12.600 --> 01:27:15.359 am very much more adult now than I was then 1567 01:27:15.720 --> 01:27:20.039 watching them, and just the the acting from these kids 1568 01:27:20.319 --> 01:27:25.399 is just incredible. It really is so good. And and 1569 01:27:25.439 --> 01:27:28.119 the writing for for how quick they were taking out 1570 01:27:28.159 --> 01:27:31.439 the first couple of seasons, like the writing in some places, 1571 01:27:31.479 --> 01:27:33.239 I was like, okay, like that could have been better, 1572 01:27:33.239 --> 01:27:37.399 But for the most part, we're just spoiled with great content, 1573 01:27:37.560 --> 01:27:43.039 like what a fun story, a great story. And yeah, 1574 01:27:43.159 --> 01:27:45.119 I was just telling my wife. Season four got a 1575 01:27:45.159 --> 01:27:48.159 little dicey because it started feeling really evil, and I 1576 01:27:48.199 --> 01:27:49.399 was like, well, I don't know if I want to 1577 01:27:49.439 --> 01:27:51.039 take part in this anymore. And then all of a 1578 01:27:51.039 --> 01:27:53.920 sudden it went super sci fi and I was like, okay, 1579 01:27:53.960 --> 01:27:59.039 this is awesome. So yeah, we've been watching Stranger Things 1580 01:27:59.079 --> 01:28:02.880 and that's about the only like one episode at night 1581 01:28:02.960 --> 01:28:06.880 and then I'm asleep, so that's about the amount of 1582 01:28:06.880 --> 01:28:08.119 time that I have to consume. 1583 01:28:08.399 --> 01:28:11.600 How old are your kids, if I might ask, I. 1584 01:28:11.600 --> 01:28:15.720 Have a a seven year old, a four year old, 1585 01:28:16.039 --> 01:28:20.520 and a almost two year old, So well, I'm not 1586 01:28:21.119 --> 01:28:25.960 they're not watching Stranger Things right now? For them? Is 1587 01:28:26.119 --> 01:28:28.760 I just really I just introduced them to spy kids 1588 01:28:30.119 --> 01:28:33.600 and they are like, this is the coolest series ever made, 1589 01:28:34.319 --> 01:28:37.239 So you know, they're they're living in a different world 1590 01:28:37.319 --> 01:28:41.359 right now. That's just as cool, but way more child friendly. 1591 01:28:42.079 --> 01:28:44.680 No, I was asking for the perspective of your free 1592 01:28:44.720 --> 01:28:48.119 time because, like Ryan said, then you have little children 1593 01:28:48.159 --> 01:28:48.520 at home. 1594 01:28:48.880 --> 01:28:51.880 Yeah, we both have little children, and I know that 1595 01:28:52.159 --> 01:28:56.039 I know from talking to Fran that they consume, happily 1596 01:28:56.359 --> 01:29:00.520 consume a lot of our time. So yeah, I it's 1597 01:29:00.560 --> 01:29:03.840 basically at night for maybe an hour that you know, 1598 01:29:03.880 --> 01:29:06.640 we get to indulge in something. 1599 01:29:06.760 --> 01:29:10.000 So all I can say though is from watching from 1600 01:29:10.039 --> 01:29:13.399 the other side as it were enjoyed while it lasts. 1601 01:29:13.520 --> 01:29:15.159 Yes, oh yeah for sure. 1602 01:29:15.279 --> 01:29:18.680 Yeah, mine are twenty five, about to get married twenty 1603 01:29:18.720 --> 01:29:23.439 two and Congratulateen, and so yeah, we have a lot 1604 01:29:23.479 --> 01:29:26.239 more a little more free time. But yeah, I missed 1605 01:29:26.279 --> 01:29:28.119 some of those. I'm looking forward to grandkids and be 1606 01:29:28.199 --> 01:29:30.079 able to have the kids into then say here you go, 1607 01:29:31.279 --> 01:29:31.560 you know. 1608 01:29:31.680 --> 01:29:35.000 Yeah, well my baby goes twenty three years old working 1609 01:29:35.039 --> 01:29:35.479 in tech. 1610 01:29:36.720 --> 01:29:37.199 Very cool. 1611 01:29:37.800 --> 01:29:40.159 Yeah all right, So with that, we're going to wrap 1612 01:29:40.199 --> 01:29:42.239 this up and hopefully we'll have these two backing in 1613 01:29:42.319 --> 01:29:45.840 to continue our discussion in the meantime. Thanks for watching 1614 01:29:45.880 --> 01:29:48.159 slash listening, and we'll talk at you next time. 1615 01:29:48.279 --> 01:29:50.880 Bye.