WEBVTT 1 00:00:05.160 --> 00:00:08.919 Hello, everybody, Welcome to another exciting episode of JavaScript Shabber. 2 00:00:08.960 --> 00:00:11.039 I am Steve Edwards, the host with the face for 3 00:00:11.199 --> 00:00:13.039 radio and the voice for being a mime, and if 4 00:00:13.039 --> 00:00:16.440 you're watching on TV you can see that. And I'm 5 00:00:16.480 --> 00:00:19.480 here with co panelist mister Dan Shapiro. How you doing, Dan, 6 00:00:20.519 --> 00:00:21.399 I'm doing great. 7 00:00:21.600 --> 00:00:24.960 Hi from Tel Aviv. Is it still hot and dry, 8 00:00:26.399 --> 00:00:29.039 isn't it always? Oh? Yes, yeah, it's good. 9 00:00:29.160 --> 00:00:31.199 We got really we got up in the nineties, fair 10 00:00:31.320 --> 00:00:35.000 nine here recently, but it's a little cooler and cloudier today, 11 00:00:35.000 --> 00:00:38.960 which is always a bummer. But anyway, our special guest 12 00:00:39.079 --> 00:00:41.479 is mister Ryan Christian. How are you doing, Ryan? 13 00:00:42.359 --> 00:00:42.840 Doing great? 14 00:00:42.920 --> 00:00:43.240 Thank you? 15 00:00:43.960 --> 00:00:47.960 So before we dive into the topic of Preact, once 16 00:00:48.000 --> 00:00:51.079 you tell people who you are, why you're famous, why 17 00:00:51.119 --> 00:00:53.159 they should give you money, where they can give you money, 18 00:00:53.240 --> 00:00:53.679 et cetera. 19 00:00:54.719 --> 00:00:59.759 Oh man, I wish. 20 00:00:57.560 --> 00:01:02.840 Well, I'm all the people working on open source super rich. Yeah, yeah, 21 00:01:02.920 --> 00:01:03.280 I hear. 22 00:01:03.759 --> 00:01:07.200 The Larry Belle guy has a lambo soul waiting for 23 00:01:07.239 --> 00:01:13.280 mine to come in, still waiting for one. So my 24 00:01:13.359 --> 00:01:16.079 name is Ryan Christian. I'm a core maintainer of Preact 25 00:01:16.120 --> 00:01:18.480 and have been for the past about four and a 26 00:01:18.480 --> 00:01:22.840 half years now. Preact, for those unware, is a job 27 00:01:22.920 --> 00:01:27.560 script UI library, and as the name can sort of suggest, 28 00:01:28.120 --> 00:01:31.400 it is largely API compatible with React and shares a 29 00:01:31.400 --> 00:01:34.519 lot of similarities with it in terms of how you 30 00:01:34.599 --> 00:01:37.920 use it and some of the API constructs. I guess 31 00:01:37.920 --> 00:01:39.599 where we diverge a little bit, just give a little 32 00:01:39.640 --> 00:01:42.599 bit more information, is we're kind of more focused on size. 33 00:01:43.000 --> 00:01:46.599 The core library is about four kb these days four 34 00:01:46.599 --> 00:01:49.840 and a half kb, contrary to our marketing line, which 35 00:01:50.000 --> 00:01:53.200 will be updated shortly. And we also kind of focus 36 00:01:53.200 --> 00:01:55.959 on performance a little bit more heavily than React does. 37 00:01:57.439 --> 00:02:00.560 And that terms React I think comes about across the 38 00:02:00.560 --> 00:02:04.239 wire about sixty kV these days fifty eight. So there's 39 00:02:04.280 --> 00:02:07.640 a quite big floor in difference in terms of the 40 00:02:07.640 --> 00:02:09.960 size of libraries and how they can be used. 41 00:02:11.120 --> 00:02:14.080 So I have to ask a question about that. I 42 00:02:14.199 --> 00:02:18.000 know that well. First of all, going back a little 43 00:02:18.000 --> 00:02:20.599 bit in history, pre Act was created by originally by 44 00:02:20.639 --> 00:02:26.120 Jesson Miller, and as I recall, he created it because 45 00:02:26.280 --> 00:02:29.840 his attitude was that in order to properly understand something, 46 00:02:30.039 --> 00:02:33.919 he needs to effectively rebuild it, and he rebuilt it 47 00:02:34.000 --> 00:02:37.719 so well that it became very successful and on its own. 48 00:02:38.800 --> 00:02:41.199 By the way, we were talking about this before we 49 00:02:41.240 --> 00:02:46.039 started recording people, I don't think people necessarily realize how 50 00:02:46.120 --> 00:02:51.319 popular pre act actually is in terms of by the 51 00:02:51.319 --> 00:02:54.080 way you called it a library, why don't you call 52 00:02:54.120 --> 00:02:55.000 it a framework? 53 00:02:57.280 --> 00:03:01.000 I guess my view is, I guess the older view 54 00:03:01.080 --> 00:03:03.919 of a library is something you call in, something you use, 55 00:03:04.080 --> 00:03:08.159 you manage to put in your existing app, or however 56 00:03:08.199 --> 00:03:11.520 you want to do it. We generally don't prescribe solutions. 57 00:03:11.520 --> 00:03:14.280 We don't require you to use it in certain ways. 58 00:03:15.360 --> 00:03:17.800 It's a have toolkits that you can use however you 59 00:03:17.800 --> 00:03:22.000 see fit, which from my understanding is for my use 60 00:03:22.039 --> 00:03:24.919 I suppose is better fit towards the library side of 61 00:03:24.919 --> 00:03:26.639 the spectrum than framework. 62 00:03:28.599 --> 00:03:34.800 But yeah, it is nuanced. I use the kind of 63 00:03:34.840 --> 00:03:39.159 definitions that I used to use was that with and 64 00:03:39.199 --> 00:03:40.919 I know that a lot of people still use them. 65 00:03:41.080 --> 00:03:43.759 AJ for example, I know likes to use. This distinction 66 00:03:44.639 --> 00:03:49.000 is that with the library, your application code calls into 67 00:03:49.039 --> 00:03:52.199 the library, and with the framework, it's the framework that 68 00:03:52.280 --> 00:03:56.759 calls into your application code. I've kind of modified the 69 00:03:56.800 --> 00:03:59.560 way that I look at it. The way that I 70 00:03:59.599 --> 00:04:04.759 look at it is that frameworks prescribe certain architectures, whereas 71 00:04:04.879 --> 00:04:09.159 libraries do not. So that's kind of the distinction that 72 00:04:09.199 --> 00:04:12.319 I make these days. So you would say that Preact 73 00:04:12.439 --> 00:04:16.319 does not kind of describe a certain architecture. 74 00:04:16.160 --> 00:04:20.160 No, I mean, we generally leave that up to users. 75 00:04:20.160 --> 00:04:22.879 They can decide how to do it. We're only concerned 76 00:04:22.920 --> 00:04:28.600 with components and how you build out your you know, 77 00:04:28.800 --> 00:04:30.720 veed on library and whatnot or vt on tree. 78 00:04:30.759 --> 00:04:35.279 Excuse me, so coming coming from the view view standpoint, 79 00:04:35.600 --> 00:04:39.560 you know, I haven't really developed with reacting and myself, 80 00:04:40.000 --> 00:04:43.600 so I'm just curious trying to understand how Preact works 81 00:04:43.639 --> 00:04:46.600 and React. So if I have a pre Act project 82 00:04:46.720 --> 00:04:49.160 in my package at Jason, do I only have Preact 83 00:04:49.759 --> 00:04:53.120 and then that depends on the React library or how 84 00:04:53.199 --> 00:04:55.920 is it that you have this this this much smaller 85 00:04:56.040 --> 00:04:59.319 version of React. Does it have all the functionality of 86 00:04:59.360 --> 00:05:02.399 React itself or just a limited set of functionality? 87 00:05:03.000 --> 00:05:06.759 Sure, so that's a great question. Preact core itself, Preact 88 00:05:06.759 --> 00:05:09.879 is split into a bunch of sub packages. We have 89 00:05:09.959 --> 00:05:13.319 the main Preact library that you install, and that comes 90 00:05:13.360 --> 00:05:16.079 with a core of like I mentioned about four and 91 00:05:16.120 --> 00:05:20.040 a half kb of content that has mostly focused on 92 00:05:20.120 --> 00:05:24.279 class components. However, We have add ons which add different 93 00:05:24.279 --> 00:05:28.680 API constructs, such as Preact slash hooks, so it's installed 94 00:05:29.000 --> 00:05:31.959 with the Preact library and bundled into the Preact library, 95 00:05:32.319 --> 00:05:36.920 but hooks you have an optional add on. Compat is 96 00:05:36.959 --> 00:05:40.920 another thing that we look at. So our compatibility with 97 00:05:41.040 --> 00:05:46.519 React comes from another subpackage, Preact compat, which is about 98 00:05:46.800 --> 00:05:50.439 ninety five percent compatible with React. But we diverge in 99 00:05:50.480 --> 00:05:55.480 some pretty big ways, namely around the event system. React 100 00:05:55.639 --> 00:05:58.360 uses their own synthetic event system. They do not use 101 00:05:58.399 --> 00:06:02.639 the vanilla events that you find in the dom. Well 102 00:06:02.720 --> 00:06:07.120 they still do, yeah, and they'll probably have to do 103 00:06:07.160 --> 00:06:09.920 so forever because that would be one hell of a 104 00:06:09.959 --> 00:06:14.879 breaking change at this point. So that is a huge 105 00:06:14.920 --> 00:06:17.720 ton of huge, massive code, and where a bunch of 106 00:06:17.759 --> 00:06:20.199 that size comes from. I know a couple of years ago, 107 00:06:20.360 --> 00:06:23.319 is something like twenty twenty five kb just for the 108 00:06:23.360 --> 00:06:27.160 event system. They also do a bunch of event delegation 109 00:06:27.279 --> 00:06:31.800 by default, which again is just more code, as well 110 00:06:31.839 --> 00:06:34.920 as a lot of their newer concurrent features, so you 111 00:06:34.959 --> 00:06:40.000 can have like two different trees rendered or in memory 112 00:06:40.040 --> 00:06:44.040 at one point. We don't do that. We are generally 113 00:06:44.040 --> 00:06:46.439 more focused on web standards and keeping the kind of 114 00:06:46.439 --> 00:06:51.639 core library small, so the core is kind of focused, 115 00:06:51.639 --> 00:06:55.639 but we do have compatibility with React, and that just 116 00:06:55.759 --> 00:06:59.879 adds that links into existing reacts libraries that you might 117 00:06:59.879 --> 00:07:04.000 have your package Jason or whatever, and kind of converts 118 00:07:04.439 --> 00:07:07.319 the React vedam shape and the React constructions some of 119 00:07:07.319 --> 00:07:11.079 the React ideas into what Preact understands. So if you 120 00:07:11.120 --> 00:07:15.240 have a Preact project, you're only using Preact, we alias 121 00:07:15.319 --> 00:07:20.680 out React for Preact compat if that makes sense. 122 00:07:20.800 --> 00:07:23.519 So then Preact itself is small, but you still got 123 00:07:23.560 --> 00:07:28.000 some other dependencies. 124 00:07:26.560 --> 00:07:30.800 Sorry, sort of it. Those dependencies are in prec. I 125 00:07:30.839 --> 00:07:34.240 mean those dependencies are part of Preact. Our compatibility layer 126 00:07:34.319 --> 00:07:35.120 is part of Preact. 127 00:07:36.800 --> 00:07:40.160 Yeah, you can clear because you kind of in you 128 00:07:40.240 --> 00:07:43.279 alluded to it. And it's important to make this point. 129 00:07:43.439 --> 00:07:47.439 Preact is not dependent on React in any way, shape 130 00:07:47.519 --> 00:07:50.920 or form. When you use the project with Preact, it's 131 00:07:51.000 --> 00:07:55.279 just Preact. It's compatible with React, it's not built on React. 132 00:07:55.439 --> 00:07:57.000 Yeah, completely separ things. 133 00:07:57.319 --> 00:08:01.079 So you're basically just taking the most important stuff and 134 00:08:01.120 --> 00:08:05.959 put it in a separate that has the similar you know, functionality. 135 00:08:06.839 --> 00:08:08.160 It's almost like you're mimicking it. 136 00:08:08.560 --> 00:08:12.240 Yeah, yes, form, Yeah exactly. We take the APIs and 137 00:08:12.279 --> 00:08:14.040 we mimic them and try to recreate them in a 138 00:08:14.399 --> 00:08:18.319 smaller form that works for our needs. Okay, yeah, that 139 00:08:18.319 --> 00:08:21.560 React knowledge and still the effective and functional. 140 00:08:22.040 --> 00:08:24.399 So I've not used pre Act in a while to 141 00:08:24.519 --> 00:08:29.519 my detriment. So we were talking before about the usage 142 00:08:29.600 --> 00:08:33.360 were The fact is that Preact is the number one 143 00:08:34.519 --> 00:08:40.600 framework slash view library out there. It's it's used as 144 00:08:40.679 --> 00:08:44.279 much as all the other frameworks combined. Just so we 145 00:08:44.399 --> 00:08:49.840 have a total size, View is about somewhere between forty 146 00:08:49.919 --> 00:08:52.679 percent and a half. I'm basically the numbers I'm using 147 00:08:53.360 --> 00:08:57.399 are from the Google Crux, which basically looks at the 148 00:08:57.480 --> 00:09:01.639 numbers of origins. You can have other measurements like the 149 00:09:01.759 --> 00:09:06.320 number of NPM downloads and stuff like that. I guess 150 00:09:06.360 --> 00:09:12.279 they're kind of aligned, but probably a bit different. View 151 00:09:12.519 --> 00:09:15.440 is like about somewhere between half and forty percent of 152 00:09:15.519 --> 00:09:19.080 React and pre Act is about thirty percent of React, 153 00:09:19.279 --> 00:09:26.519 which doesn't leave a whole lot for all the other frameworks. Yeah, 154 00:09:26.559 --> 00:09:30.639 when you think about it, but it does mean that 155 00:09:30.879 --> 00:09:34.639 Preact is a third of React, which is the leading 156 00:09:34.840 --> 00:09:37.720 front and framework, which is a lot. You're used by 157 00:09:37.919 --> 00:09:41.879 thousands of sites and web application hundreds, well, actually hundreds 158 00:09:41.919 --> 00:09:42.759 of thousands, I will. 159 00:09:42.759 --> 00:09:45.200 Yeah, And there's something a little bit more interesting there 160 00:09:45.240 --> 00:09:48.639 is because preact has this focus on small size, it 161 00:09:48.720 --> 00:09:51.360 is especially well suited for widgets. 162 00:09:52.159 --> 00:09:52.440 I know. 163 00:09:52.480 --> 00:09:55.320 I think a number of major websites use Preact on 164 00:09:55.399 --> 00:09:59.120 it to the point where Jason quotes a figure Jason Miller, 165 00:09:59.279 --> 00:10:02.759 who created quotes figure that Preactive be found on about 166 00:10:02.840 --> 00:10:06.039 six percent of sites these days, or major sites used. 167 00:10:07.159 --> 00:10:11.080 So this isn't necessarily as the main view library or 168 00:10:11.240 --> 00:10:14.679 the main driver of all interactivity, but that it can 169 00:10:14.720 --> 00:10:18.679 be found on a huge portion of the web just 170 00:10:18.720 --> 00:10:20.879 because it could be used for those kind of small, 171 00:10:21.360 --> 00:10:22.600 self contained widgets. 172 00:10:23.200 --> 00:10:25.840 So that kind of brings out a point that I 173 00:10:25.879 --> 00:10:29.279 was thinking about, because these days, when you consider this 174 00:10:29.440 --> 00:10:33.840 typical size of a web site or web certainly of 175 00:10:33.879 --> 00:10:38.799 a web application, they're pretty huge. And they're huge mostly 176 00:10:38.879 --> 00:10:44.039 because of either user code or because of the whole 177 00:10:44.080 --> 00:10:47.799 bunch of NPM stuff that people just bundle into their 178 00:10:47.799 --> 00:10:51.759 web applications, to the extent that the twenty to thirty 179 00:10:51.840 --> 00:10:56.480 K difference between Preact and React is not necessarily a 180 00:10:56.480 --> 00:10:59.240 whole lot at the end of the day, or do 181 00:10:59.279 --> 00:11:00.480 you disagree. 182 00:11:00.720 --> 00:11:04.120 Well, it's closer to fifty k these days, and sure 183 00:11:04.879 --> 00:11:08.960 when you start building massive websites, that is indeed going 184 00:11:08.960 --> 00:11:12.240 to be swallowed up by you know, node modules or 185 00:11:12.639 --> 00:11:16.039 user code. I was looking at the open ai site 186 00:11:16.039 --> 00:11:18.080 the other day and I think it downloads something like 187 00:11:18.120 --> 00:11:21.679 three megs of JavaScript. Fifty kb is not going to 188 00:11:21.720 --> 00:11:22.720 make a difference there. 189 00:11:23.879 --> 00:11:27.639 Gesip three megs or yeah. 190 00:11:27.960 --> 00:11:31.159 Yeah, it has no code splitting whatsoever, so it loads 191 00:11:31.480 --> 00:11:33.919 absolutely everything. Did you guys not see that? There was 192 00:11:34.000 --> 00:11:37.759 the article between Sam Altman and Jonie I've that came 193 00:11:37.799 --> 00:11:41.120 out a couple of weeks ago. It's a static page, 194 00:11:41.279 --> 00:11:43.960 just has a single you know, BIV text, single video, 195 00:11:44.279 --> 00:11:47.080 and it loads three megs of jobscript because it's a 196 00:11:47.240 --> 00:11:50.240 next yess app with no codes playing whatsoever. So it 197 00:11:50.279 --> 00:11:53.279 loads all of the you know, chat g ept and 198 00:11:53.279 --> 00:11:56.919 stuff into it. It's bad. Wow, yeah, but. 199 00:11:57.600 --> 00:12:00.360 So fifty K. It's not about perform months. 200 00:12:01.720 --> 00:12:06.080 Yeah. So yeah, in that case, it's not gonna make 201 00:12:06.080 --> 00:12:09.120 a difference. And we don't proclaim that it would. It's 202 00:12:09.559 --> 00:12:12.919 we don't proclaim that preact, you know, adding swapping out 203 00:12:12.960 --> 00:12:17.720 react and switch preacts can change anything on its own. However, 204 00:12:17.799 --> 00:12:23.120 it does vastly reduce the floor I know, Alex Russell 205 00:12:23.320 --> 00:12:26.000 of previous Chrome pain and now he works on Blink, 206 00:12:27.039 --> 00:12:27.519 comes out. 207 00:12:27.440 --> 00:12:29.720 With a guest on this podcast several times. 208 00:12:30.039 --> 00:12:32.440 Yeah, he comes out every couple of years with a 209 00:12:32.519 --> 00:12:36.200 job script budget to kind of talk about what should 210 00:12:36.200 --> 00:12:39.080 be our height of job script for the current low 211 00:12:39.159 --> 00:12:43.440 end devices and you know users and fifty KB in 212 00:12:43.519 --> 00:12:45.600 terms of those budgets, which I think are about said 213 00:12:45.600 --> 00:12:48.919 about three hundred K these days, three hundred KB. Fifty 214 00:12:49.039 --> 00:12:51.639 k is quite a bit, as you know, one six 215 00:12:51.720 --> 00:12:54.840 year total budget that could be reduced if you did 216 00:12:54.840 --> 00:12:58.320 switch to Preact, and that could be you know, fifty 217 00:12:58.399 --> 00:13:03.279 k on every page. Combined with some other opportunities. It 218 00:13:04.080 --> 00:13:06.879 adds some extra room to add UX features or d 219 00:13:07.080 --> 00:13:07.919 X stuff. 220 00:13:08.399 --> 00:13:12.120 Oh for sure. And like you also said, it's in 221 00:13:12.279 --> 00:13:15.840 very interesting use cases the widget scenario where you want 222 00:13:15.879 --> 00:13:20.159 to add something to a page that already potentially has 223 00:13:20.200 --> 00:13:23.240 some framework on it and you don't want to overload 224 00:13:23.279 --> 00:13:25.399 that page even more exactly. 225 00:13:25.480 --> 00:13:28.879 Yeah, that's quite usedful. 226 00:13:29.159 --> 00:13:35.440 Now you did mention that in terms of the way 227 00:13:35.519 --> 00:13:40.000 that the core Preact works, you're still focused on class 228 00:13:40.039 --> 00:13:44.759 components rather than hooks. Are most people using Preact with 229 00:13:45.399 --> 00:13:48.279 as far as you know, with classes or with hooks, 230 00:13:48.360 --> 00:13:53.200 because with React itself it's hooks all the way these days. 231 00:13:54.080 --> 00:13:56.799 Yeah, so I think hooks are definitely more popular, and 232 00:13:56.879 --> 00:13:59.679 I should mention signals. It's another kind of state primitive 233 00:13:59.720 --> 00:14:01.879 re add on top a couple of years ago. You 234 00:14:01.919 --> 00:14:04.720 can use those with function components or class components. They're 235 00:14:04.799 --> 00:14:09.399 kind of their own separate thing. But while hooks are popular, 236 00:14:09.559 --> 00:14:13.759 they are just an optional add on and Preact so 237 00:14:13.879 --> 00:14:16.039 you can use hooks if you want them, if you 238 00:14:16.039 --> 00:14:18.240 don't want them, they're going to cost nothing to your bundle. 239 00:14:18.279 --> 00:14:21.960 They are in a subpath, so you can say, hey, 240 00:14:22.000 --> 00:14:26.080 I just want the lightest toolkit that can use, so 241 00:14:26.120 --> 00:14:28.879 you just use the core Preact library and just use 242 00:14:28.879 --> 00:14:32.519 class components go which you need done. And that's kind 243 00:14:32.519 --> 00:14:34.600 of the interesting way that Preact to structured. We have 244 00:14:34.679 --> 00:14:38.960 a plugable renderer with a public API, so people can 245 00:14:39.039 --> 00:14:43.200 come and add existing like add ons and state primitives 246 00:14:44.000 --> 00:14:47.080 tying into the render cycle if they want, and they 247 00:14:47.120 --> 00:14:48.960 can use the exact same tools that we use to 248 00:14:49.120 --> 00:14:53.799 build out our add ons, like compat, hooks, signals. More recently, 249 00:14:54.440 --> 00:14:57.600 all that stuff, it's all public API. 250 00:14:58.240 --> 00:15:02.639 Now. Looking at the directions in which React is moving, 251 00:15:02.720 --> 00:15:05.240 and I'm kind of interested in contrasting some of them 252 00:15:05.240 --> 00:15:09.679 with Preact, especially since, for our conversation before you're about 253 00:15:09.720 --> 00:15:13.480 to release a new version of PREACTI pretty soon. One 254 00:15:13.519 --> 00:15:17.399 of the core things about React for several years now, 255 00:15:17.960 --> 00:15:20.200 and I think you mentioned it, is the whole fiber 256 00:15:20.320 --> 00:15:26.159 thing and the concurrent stuff and the suspense and stuff 257 00:15:26.159 --> 00:15:30.440 like that. Do you have anything like suspense built into Preact. 258 00:15:31.120 --> 00:15:35.519 Yeah, Suspense has been part Preact for years now. It 259 00:15:35.600 --> 00:15:37.960 is essentially in the same state. That is and React 260 00:15:39.320 --> 00:15:41.840 more or less. You can use it for all sorts 261 00:15:41.840 --> 00:15:46.200 of things like lazy loading, data hatching, asynchronous actions, whatnot. 262 00:15:46.720 --> 00:15:51.799 That's all there. We, however, are less interested in following 263 00:15:51.879 --> 00:15:57.960 React into things like concurrent mode and current features. Their 264 00:15:58.000 --> 00:15:59.960 implementation is server components. 265 00:16:01.120 --> 00:16:03.679 Yeah, we'll get to that. Let's let's put that to 266 00:16:03.720 --> 00:16:06.320 the side, because I will want to go there. But 267 00:16:06.720 --> 00:16:09.799 just to clarify to our to our listeners who may 268 00:16:09.879 --> 00:16:14.960 or may not know, suspense is basically about making the 269 00:16:15.000 --> 00:16:19.360 rendering of certain certain things, certain components a synchronous to 270 00:16:19.399 --> 00:16:22.240 the rest of the page, and they can have a 271 00:16:22.279 --> 00:16:27.279 loading state while they're getting retrieving the data and they 272 00:16:27.320 --> 00:16:29.679 are not They don't block the rest of the page, 273 00:16:29.720 --> 00:16:32.840 and when they get the data, they can then update 274 00:16:32.879 --> 00:16:35.840 themselves with the data. I like to say that the 275 00:16:35.879 --> 00:16:39.559 way that you can identify modern web applications is that 276 00:16:39.679 --> 00:16:42.919 instead of one big spinner, we now have lots of 277 00:16:43.000 --> 00:16:44.039 little spinners. 278 00:16:44.840 --> 00:16:46.720 Yeah. 279 00:16:46.960 --> 00:16:49.879 Yeah, that was actually what I've talked about this before 280 00:16:49.919 --> 00:16:51.919 on Views on View and might have been here. But 281 00:16:52.039 --> 00:16:56.480 View three added that feature, so it's native. It's just 282 00:16:56.519 --> 00:17:00.240 super easy now to say, okay, while it's loading, shows this, 283 00:17:00.320 --> 00:17:03.000 and then once it's loaded, then show the data. Where 284 00:17:03.039 --> 00:17:06.079 before it was like said a loading variable. Okay, so 285 00:17:06.160 --> 00:17:08.240 it's loading, so show this gift. And now it's loaded, 286 00:17:08.279 --> 00:17:10.359 so you can unset that variable and show the data. 287 00:17:10.359 --> 00:17:13.359 And so it was a very very nice convenience feature 288 00:17:13.359 --> 00:17:14.319 added of View three. 289 00:17:14.839 --> 00:17:19.359 Yeah, and reacts and preact. There are certainly more performance 290 00:17:19.359 --> 00:17:23.160 considerations with it, especially just the way it works as 291 00:17:23.240 --> 00:17:28.640 promises are essentially thrown up through the component tree. We 292 00:17:28.680 --> 00:17:33.119 don't necessarily love it as a primitive. It certainly has 293 00:17:33.119 --> 00:17:37.079 some bad performance footguns, but it is something that's been 294 00:17:37.119 --> 00:17:39.440 the framework for years and you can make use of 295 00:17:39.480 --> 00:17:41.839 it intelligently. 296 00:17:42.759 --> 00:17:45.599 So what do you kind of recommend it potentially instead. 297 00:17:46.359 --> 00:17:49.640 Generally extracting all sorts of day of hatching out of 298 00:17:49.680 --> 00:17:53.079 the render tree entirely. This is something that Jason has 299 00:17:53.119 --> 00:17:56.920 talked about a bit on I think like the his 300 00:17:57.440 --> 00:18:01.119 VT talk of last year, so twenty twenty four. It's 301 00:18:01.119 --> 00:18:02.920 something that the remix guys have been talking about for 302 00:18:03.000 --> 00:18:06.960 a while in that if you put your data fetching 303 00:18:07.279 --> 00:18:10.559 at the component level, you're only going to trigger those 304 00:18:10.559 --> 00:18:15.839 requests as or once the page loads, and that creates 305 00:18:15.880 --> 00:18:19.640 waterfalls and all sorts of delays that could otherwise be 306 00:18:19.680 --> 00:18:23.759 avoided by hoisting. So you take all those data fetches, 307 00:18:24.200 --> 00:18:26.440 you create either you know, like a page level loader 308 00:18:27.079 --> 00:18:30.799 or just manual hoisting with things like you know fetch 309 00:18:30.880 --> 00:18:33.640 or graph qul is great for this, and you track 310 00:18:33.720 --> 00:18:37.039 that completely outside the render tree and have it live 311 00:18:37.079 --> 00:18:41.680 outside entirely. So you load the main bundle, you fire 312 00:18:41.720 --> 00:18:44.000 off all those patches, and once you get that data, 313 00:18:44.079 --> 00:18:45.200 then you start rendering. 314 00:18:47.640 --> 00:18:51.559 And then how do you propagate the data into the components? 315 00:18:51.559 --> 00:18:56.319 So put it in an alternative way, what state management solutions 316 00:18:56.359 --> 00:19:00.680 do people usually use on the client side with preact 317 00:19:00.759 --> 00:19:04.240 in order to propagate this data into the components. 318 00:19:03.839 --> 00:19:06.799 The contact API is great contact API has been there 319 00:19:06.799 --> 00:19:09.960 forever and you can you know, initialize your app just 320 00:19:09.960 --> 00:19:15.480 pass data into the root you know. App component signals 321 00:19:15.480 --> 00:19:17.359 in more recent years have been great for that too. 322 00:19:18.359 --> 00:19:22.359 So signals are a reactivity primitive that we added in 323 00:19:22.599 --> 00:19:26.319 September of twenty twenty two, So you can very very 324 00:19:26.359 --> 00:19:31.680 easily have state that exists outside of your tree. It's reactive, 325 00:19:31.759 --> 00:19:35.200 you can change it however you want. And there's also 326 00:19:35.279 --> 00:19:38.720 tie into the component life cycle, so when that data changes, 327 00:19:39.680 --> 00:19:44.440 you know, components will update themselves or update text content, whatever, 328 00:19:44.960 --> 00:19:47.079 so they can tie into that global store idea. 329 00:19:47.839 --> 00:19:50.759 So we had Joe Savona and Sati on the show 330 00:19:50.799 --> 00:19:53.039 a while back and one of the things that came 331 00:19:53.119 --> 00:19:57.279 up in the conversation worse signals, and Joe was pretty 332 00:19:59.160 --> 00:20:02.519 frank on the point that React is not going to 333 00:20:02.519 --> 00:20:06.319 support signals. It's not part of their vision. Or actually 334 00:20:06.400 --> 00:20:09.839 put it more accurately said, if signals becomes a core 335 00:20:09.960 --> 00:20:13.880 feature of JavaScript itself, then they will support the JavaScript signals, 336 00:20:14.200 --> 00:20:17.440 but otherwise they don't plan to integrate signals into React. 337 00:20:17.920 --> 00:20:20.640 I know that, like you mentioned, Preact has had signals 338 00:20:20.640 --> 00:20:24.720 for a while. Now do basically do signal our signals 339 00:20:24.759 --> 00:20:29.519 in Preact used to trigger the re render of a component. 340 00:20:31.039 --> 00:20:34.839 So yes and no. So signals have a very deep 341 00:20:35.240 --> 00:20:38.920 integration with React. We do actually with Preact, excuse me, 342 00:20:39.240 --> 00:20:43.279 we do also have a React integration. So if users wanted, 343 00:20:43.400 --> 00:20:45.880 we do have a signals integration that they can use. 344 00:20:46.839 --> 00:20:52.000 But for Preact there's kindy modes where you can use 345 00:20:52.039 --> 00:20:55.960 a signal within your JSX as a direct text binding 346 00:20:56.160 --> 00:21:00.200 or a atropute binding, and that if that signal updates, 347 00:21:00.440 --> 00:21:03.240 it will change only say like a text value within 348 00:21:03.279 --> 00:21:06.279 the JSX. It will not re render the entire component. 349 00:21:06.720 --> 00:21:09.960 It does it at the granular, very specific level. 350 00:21:10.480 --> 00:21:12.680 So what is known as fine grain reactivity. 351 00:21:13.000 --> 00:21:18.559 Yes, exactly, you can if you want to reference the signal, 352 00:21:18.960 --> 00:21:23.240 unwrap it within the actual component function and that will 353 00:21:24.079 --> 00:21:27.839 subscribe the component essentially to the signal and will rerender it. 354 00:21:29.240 --> 00:21:31.519 You don't need to do that, You don't necessarily need 355 00:21:31.559 --> 00:21:36.279 to use the fine grain reactivity. Our signals implementation isn't 356 00:21:36.319 --> 00:21:39.559 necessarily focused on fine grain reactivity, as other tools like 357 00:21:39.640 --> 00:21:43.519 solid kind of folks on I think speltz runes are similar. 358 00:21:44.400 --> 00:21:47.759 Our signals are meant to complement VDOM and provide a 359 00:21:48.119 --> 00:21:51.920 more performance solution to those cases where you do want 360 00:21:52.039 --> 00:21:55.920 fine grained reactivity when that could be valuable, But you're 361 00:21:55.960 --> 00:21:58.799 not throwing out the baby with the bathwater. You still 362 00:21:58.880 --> 00:22:01.839 do have the component model, you still have free renders. 363 00:22:02.680 --> 00:22:06.000 That's still a kind of primitive and solid building boket 364 00:22:06.000 --> 00:22:06.400 build on. 365 00:22:07.240 --> 00:22:10.039 So basically you're saying that in terms of context, when 366 00:22:10.079 --> 00:22:13.759 I need to propagate updates throughout the componentry, I would 367 00:22:14.119 --> 00:22:20.799 either use something like context or signals as the means 368 00:22:20.799 --> 00:22:25.160 of getting the data from whatever state management solution I 369 00:22:25.319 --> 00:22:30.039 choose to use to the components themselves. Yeah. 370 00:22:30.119 --> 00:22:33.039 Yeah, those are the kind of favorite ways these days. 371 00:22:33.440 --> 00:22:36.160 And signals along those signs are interesting because you could 372 00:22:36.200 --> 00:22:39.960 just directly import the signal. You don't need, you know, 373 00:22:40.039 --> 00:22:43.440 like a use contextfook or anything. You can just have 374 00:22:43.480 --> 00:22:46.960 a bear signal in a module important in that signal 375 00:22:48.119 --> 00:22:50.920 and use it in your component and it's reactivity. 376 00:22:51.960 --> 00:22:55.640 Very good. By the way, do you have anything similar 377 00:22:55.720 --> 00:22:58.480 to ten stack query what used to be React Query? 378 00:23:00.319 --> 00:23:02.079 No, we don't have anything built in. I think it 379 00:23:02.160 --> 00:23:06.240 works fine with our compatibility layer. So, as we kind 380 00:23:06.240 --> 00:23:10.400 of mentioned earlier, users can add tansac query to their app. 381 00:23:10.799 --> 00:23:13.680 They set up the Preact aliases, so that just swaps 382 00:23:13.720 --> 00:23:18.519 out references of React with Preact compat in their bill 383 00:23:18.599 --> 00:23:20.880 tool of choice and it should just work. 384 00:23:23.359 --> 00:23:29.039 Now. In recent years, a React has been really focused, 385 00:23:29.480 --> 00:23:34.880 it seems, on transitioning from being a view library into 386 00:23:34.920 --> 00:23:41.839 becoming a full stack framework. Some might say that nextjs 387 00:23:41.920 --> 00:23:45.519 is kind of the future of of React in a 388 00:23:45.519 --> 00:23:48.000 lot of ways, and a lot of and some of 389 00:23:48.000 --> 00:23:51.440 the React core team members have indeed moved to Versailles, 390 00:23:52.240 --> 00:23:59.039 and the vision includes stuff like React server components like 391 00:23:59.519 --> 00:24:03.400 servers in a lot of ways, Next jays is back 392 00:24:03.440 --> 00:24:06.599 and first everything first runs on the back end. Then 393 00:24:06.640 --> 00:24:10.519 you actually need to explicitly specify that from beyond this 394 00:24:10.680 --> 00:24:15.079 point things will start executing on the client side. I 395 00:24:15.200 --> 00:24:19.759 gather that that's not the direction that you're going down 396 00:24:19.880 --> 00:24:21.960 with pre Act now. 397 00:24:23.400 --> 00:24:25.359 A lot of the React a lot of the ideas 398 00:24:25.359 --> 00:24:27.839 that the React team as present over the years are interesting. 399 00:24:28.960 --> 00:24:34.480 Server components as an idea are interesting, but we're definitely 400 00:24:34.480 --> 00:24:38.359 not looking to follow them down that path in any way. 401 00:24:40.720 --> 00:24:43.119