Transcrição completa de TMiR 2025-09: React 19.2 on the horizon; npm is still getting compromised

large lists. 00:01:36.840 --> 00:01:38.160 Mark: It's virtualizing lists. 00:01:38.160 --> 00:01:40.770 Yeah, so you got a list of, you know, a million items. 00:01:40.770 --> 00:01:43.679 You can only show a hundred on screen at once, that sort of thing. 00:01:44.100 --> 00:01:48.539 Also, on that note, Apollo client for GraphQL just put out version 4.0. 00:01:48.750 --> 00:01:51.750 I know this was a, a pretty major effort to try to improve 00:01:51.750 --> 00:01:53.759 the packaging, consolidate. 00:01:54.285 --> 00:01:58.005 Remove a bunch of deprecated features, so that should be a significant 00:01:58.005 --> 00:01:59.324 improvement if you're using Apollo. 00:01:59.565 --> 00:02:04.514 And on my side, I actually just shipped a Redux toolkit 2.9 earlier this month. 00:02:04.964 --> 00:02:09.914 The biggest thing there is I made a bunch of perf optimizations to RTK 00:02:09.914 --> 00:02:14.415 query, especially for cases where you've got a lot of components that 00:02:14.415 --> 00:02:16.515 are reading from the same cache entry. 00:02:16.905 --> 00:02:20.625 And we also added a few new options and bug fixes, but the perf improvement and 00:02:20.625 --> 00:02:24.285 some in-flight requests cleanup was, were some of the biggest pieces there. 00:02:25.050 --> 00:02:25.440 Carl: Okay. 00:02:25.560 --> 00:02:25.920 Yeah. 00:02:26.100 --> 00:02:29.880 Not too many new releases for open source libraries this month, I guess. 00:02:30.180 --> 00:02:31.440 Mark: Well there, there probably were a few more. 00:02:31.440 --> 00:02:32.460 We just didn't collect them. 00:02:32.790 --> 00:02:35.910 Carl: Yeah, I wish there were a little bit more consistent standards 00:02:35.910 --> 00:02:39.930 across the ecosystem for how to publish a list of new releases. 00:02:40.460 --> 00:02:43.700 Like the GitHub release is, it is pretty good, but it's still 00:02:43.700 --> 00:02:45.770 only like 60% hit rate, I guess. 00:02:45.950 --> 00:02:46.460 Something like that. 00:02:46.460 --> 00:02:46.910 It feels like. 00:02:47.390 --> 00:02:47.930 Cool though. 00:02:48.320 --> 00:02:49.430 Let's go into our main content. 00:02:49.550 --> 00:02:52.100 Can you tell us a bit about React updates? 00:02:52.370 --> 00:02:56.480 Mark: I don't actually have any real details on this, but Rick Hanlon from the 00:02:56.480 --> 00:03:01.610 React team tweeted out like yesterday, a screenshot of himself apparently 00:03:01.610 --> 00:03:07.340 working on release notes for React 19.2, so I would assume it's fair to 00:03:07.340 --> 00:03:11.420 say that it's probably coming out in the near future associated with that 00:03:11.690 --> 00:03:14.840 and potentially coming out in 19.2. 00:03:14.840 --> 00:03:19.700 Although the timing may be a little too soon, we have two React features that 00:03:19.700 --> 00:03:24.140 have graduated from the experimental branch to the Canary branches. 00:03:24.740 --> 00:03:28.100 The first one is the new activity

component. 00:03:28.610 --> 00:03:32.065 This has been around in some form in in the experimental branches for. 00:03:33.060 --> 00:03:35.370 Probably multiple years at this point. 00:03:35.850 --> 00:03:40.650 It was originally known as the offscreen component, and then they officially 00:03:40.650 --> 00:03:44.970 renamed it to the activity component maybe about six or eight months ago. 00:03:45.570 --> 00:03:48.540 And this is gonna be a pretty big deal. 00:03:49.020 --> 00:03:54.630 So one of the issues with React has always been that built-in state 00:03:54.720 --> 00:03:56.255 is managed at the component level. 00:03:57.065 --> 00:04:01.595 And if you unmount a component, then it, you know, both cleans 00:04:01.595 --> 00:04:03.484 up the effects and they go away. 00:04:03.965 --> 00:04:07.835 But the state that was in that component goes away as well. 00:04:08.315 --> 00:04:12.275 And so that's one of the reasons why there's been, you know, so much use of 00:04:12.275 --> 00:04:17.075 external state libraries like, you know, Redux and Juice end and Jot and MobX 00:04:17.075 --> 00:04:22.024 over the years is because in order for state to persist, you either needed. 00:04:22.515 --> 00:04:27.255 To have the state live outside UAC component tree, or you needed to 00:04:27.255 --> 00:04:31.755 hoist it up to the top and pass it down via context or props and if 00:04:31.755 --> 00:04:35.745 you unmount a section of the tree that DA and that data could go away. 00:04:36.375 --> 00:04:43.245 So the activity component is going to allow you to essentially disable 00:04:43.335 --> 00:04:49.635 and hide a section of the component tree, but react will keep around 00:04:49.695 --> 00:04:51.825 the state for those components. 00:04:52.470 --> 00:04:56.490 And in fact this actually kind of goes along with some of the strict 00:04:56.490 --> 00:04:59.610 mode stuff that people have, you know, complained about for years. 00:05:00.150 --> 00:05:05.490 The activity component will also unmount the effects for 00:05:05.490 --> 00:05:07.530 the components that got hidden. 00:05:08.100 --> 00:05:10.740 People have complained for years, you know, strict mode, double running 00:05:10.770 --> 00:05:13.980 effects, you know, shows bugs and, and all the other things like that. 00:05:14.429 --> 00:05:20.309 But part of the point of that has been to work towards, eventually this feature 00:05:20.309 --> 00:05:24.840 will come out where you can toggle the activity component on and off. 00:05:25.340 --> 00:05:29.510 And React will run the UNM mounts because the components aren't 00:05:29.510 --> 00:05:32.539 fully mounted, therefore, they shouldn't have active effects going. 00:05:33.110 --> 00:05:37.220 But it will keep the state for those components alive. 00:05:37.700 --> 00:05:41.090 And so you can imagine this could be useful for a couple of different things. 00:05:41.120 --> 00:05:43.490 One is like a tabs component. 00:05:44.000 --> 00:05:48.439 Right now, if you have a tabs component, you either stop rendering the other 00:05:48.439 --> 00:05:53.270 tabs completely as you switch back and forth, or you use something like CSS 00:05:53.270 --> 00:05:57.890 display, none, which means the tabs are active and in the page, even though 00:05:57.890 --> 00:05:59.299 they're not even being displayed. 00:05:59.539 --> 00:06:04.640 And so with the activity component, you can say I want to pre-render 00:06:04.730 --> 00:06:09.380 the content for the other tabs, but it's not actually attached to the 00:06:09.380 --> 00:06:11.990 page until we swap back and forth. 00:06:12.230 --> 00:06:14.299 But they could still persist the state. 00:06:14.299 --> 00:06:16.520 So if someone goes back and forth between the different 00:06:16.520 --> 00:06:18.439 tabs and makes some edits, then. 00:06:19.225 --> 00:06:20.425 You know, that still stays alive. 00:06:20.905 --> 00:06:23.155 There's a comment in the chat that the naming choice for the 00:06:23.155 --> 00:06:24.865 component seems very strange to me. 00:06:25.135 --> 00:06:25.885 I agree. 00:06:26.095 --> 00:06:27.445 I didn't like it either. 00:06:27.835 --> 00:06:33.205 There was some rationale in the PR that actually renamed it to activity. 00:06:33.505 --> 00:06:36.445 I don't remember what it, what it was specifically off the top of my head, 00:06:36.895 --> 00:06:43.345 but they, I think it was that like, it's more about is the component active rather 00:06:43.345 --> 00:06:45.895 than is it quote unquote off screen. 00:06:46.135 --> 00:06:46.465 Yeah. 00:06:47.005 --> 00:06:50.575 But I, I don't entirely buy that myself. 00:06:51.025 --> 00:06:52.255 Carl: Yeah, right. 00:06:52.255 --> 00:06:57.385 Because this is like hitting that midpoint between that decision point of do you 00:06:57.385 --> 00:07:02.785 render null or do you render the dom with styling to suppress its visibility. 00:07:02.785 --> 00:07:06.145 And so I guess this is like smack in the middle, like the internal 00:07:06.145 --> 00:07:07.495 representation of all of that. 00:07:07.495 --> 00:07:08.725 Dom remains. 00:07:09.260 --> 00:07:12.980 But you don't use styling to hide it, which is great for cross-platform stuff. 00:07:13.010 --> 00:07:16.310 'cause like there wasn't a cross-platform way to hide 00:07:16.310 --> 00:07:17.900 something as far as I know before. 00:07:18.169 --> 00:07:22.820 Mark: So if I, if I look back at the last React Labs post from April where 00:07:22.820 --> 00:07:26.600 they talk about, you know, the plans for the activity component, there's a 00:07:26.600 --> 00:07:31.010 section there that says, in the future we may add more modes for activity. 00:07:31.549 --> 00:07:38.450 One of them could be content visible, but keep it unmounted and pause dom updates. 00:07:38.929 --> 00:07:43.640 Another is the ability to destroy state for hidden activities if 00:07:43.640 --> 00:07:45.590 too much memory is

being used. 00:07:46.100 --> 00:07:51.380 So I think part of the mindset is it's not just like a bullion toggle, it's 00:07:51.770 --> 00:07:56.929 we're shipping with two mode options that are like a bullion toggle for now. 00:07:57.440 --> 00:08:01.250 But we envision some possible additional modes for this down the road. 00:08:02.525 --> 00:08:05.645 Mo: And, and you know, this is like particularly interesting to me because 00:08:05.915 --> 00:08:09.455 this has like been a long standing problem in the React native space 00:08:09.455 --> 00:08:11.315 when you're dealing with native apps. 00:08:11.705 --> 00:08:15.545 And I, I doubt this will work out of the box with React Native, but I think 00:08:15.545 --> 00:08:17.645 it's gonna be one of those things which will eventually get there. 00:08:17.645 --> 00:08:20.885 And hopefully the new architecture makes this easy for the, the core 00:08:20.885 --> 00:08:24.275 team to adopt and like make sure that those APIs are working correctly. 00:08:24.635 --> 00:08:27.905 But it's a classic issue, especially when in Native world you're dealing 00:08:27.905 --> 00:08:31.115 with this concept of like stacks of pages on top of each other. 00:08:31.475 --> 00:08:35.164 You really don't want the, the stacks that aren't visible or the pages that 00:08:35.164 --> 00:08:39.275 aren't visible in your stack showing or getting all of the DOM updates, 00:08:39.455 --> 00:08:43.054 or in this case this, the updates to the actual screens whilst they're 00:08:43.054 --> 00:08:46.505 inactive because that's a massive performance bottleneck on native devices. 00:08:46.925 --> 00:08:50.525 And so this type of thing, people have massed over it in the most 00:08:50.525 --> 00:08:55.175 dirty ways possible and hacky ways possible in, in the React native world. 00:08:55.770 --> 00:08:58.560 It's been like a longstanding problem because if you, you know, 00:08:58.564 --> 00:09:01.290 unmount them and then remount them and reestablish the state, there's 00:09:01.290 --> 00:09:04.949 sometimes like a flashing white screen before the actual components reload. 00:09:05.490 --> 00:09:07.740 Then you need to delay the transition because all of these 00:09:07.829 --> 00:09:10.469 things are like transition with page transitions and native. 00:09:10.650 --> 00:09:14.699 So it's basically to say there's a lot of complexity and if there's a native 00:09:14.699 --> 00:09:18.839 React way to deal with this, that ties into navigation on the native device 00:09:18.839 --> 00:09:22.920 as well, then I think it's gonna be a game changer and it'll simplify and fix 00:09:22.920 --> 00:09:26.010 a lot of performance issues that people often have with their React native apps. 00:09:26.339 --> 00:09:29.560 Mark: Yeah, I, I know we've, we've had a couple of open issues on the `react-redux` 00:09:29.579 --> 00:09:31.500 repo with people complaining that. 00:09:32.240 --> 00:09:36.470 Components that are off, quote unquote offscreen in the React native 00:09:36.470 --> 00:09:41.000 stack are still subscribed to Redux updates and taking up perfects from 00:09:41.000 --> 00:09:46.130 running all the subscription logic and asking for us to add random options 00:09:46.130 --> 00:09:48.230 to make that toggle or something. 00:09:48.590 --> 00:09:52.100 And so if you know, the activity component ought to be the 00:09:52.100 --> 00:09:53.449 built-in solution for that. 00:09:53.990 --> 00:09:56.870 And so that would actually means we don't have to do anything, which is great. 00:09:57.199 --> 00:09:57.980 Yeah, exactly. 00:09:57.980 --> 00:10:01.790 Mo: And you know, like some state management libraries have adopted 00:10:01.790 --> 00:10:05.569 some work around components that you can use for that, but it 00:10:05.569 --> 00:10:06.590 comes with trade-offs, right? 00:10:06.590 --> 00:10:10.040 And ideally, your state management library really should not worry about this. 00:10:10.040 --> 00:10:13.370 This feels like a core react primitive problem rather than a 00:10:13.370 --> 00:10:14.840 state management library problem. 00:10:14.840 --> 00:10:15.230 To me, 00:10:15.770 --> 00:10:20.209 Carl: back to what you said about like the layering of UI and performance problems 00:10:20.209 --> 00:10:21.949 and like listening to events and things. 00:10:22.490 --> 00:10:27.350 Fun fact, I've chatted with some people who did React native or like 00:10:27.350 --> 00:10:32.420 React UI for automotive companies and that was a problem they dealt 00:10:32.420 --> 00:10:35.060 with like sometimes for certain cars. 00:10:35.060 --> 00:10:39.589 The reason the UI sucks sometimes is because of this issue and 00:10:39.589 --> 00:10:42.949 because it's rendering multiple UIs on top of each other and doing 00:10:42.949 --> 00:10:44.480 all sorts of weird, crazy stuff. 00:10:44.660 --> 00:10:45.079 There's two 00:10:45.079 --> 00:10:47.390 Mo: devices that are particularly bad for that. 00:10:47.449 --> 00:10:50.719 One is Smart TVs and the other one is cars. 00:10:50.990 --> 00:10:55.730 And the reason for that is both of them are awful processors and like 00:10:55.730 --> 00:10:59.540 they really cheap out on the hardware because they're cutting costs everywhere 00:10:59.545 --> 00:11:01.579 in the actual like manufacturing bit. 00:11:01.910 --> 00:11:04.760 And so something that might run in your web browser with your 00:11:04.760 --> 00:11:08.900 laptop that like has like several hundred megabytes of RAM per tab. 00:11:09.265 --> 00:11:13.405 Will, you know, be restricted to 50 megabytes of ram or it'll get killed 00:11:13.405 --> 00:11:17.755 by the operating system that lives on the automotive car infotainment system. 00:11:18.204 --> 00:11:23.094 And this is a big problem for any, like one of those types of devices. 00:11:23.454 --> 00:11:27.055 And I think a lot of those, you'll be surprised, run on React and like 00:11:27.055 -->

00:11:31.255 web-based platforms or sometimes even rec native, and it's a big, big issue. 00:11:31.255 --> 00:11:32.334 So I think something like this. 00:11:33.020 --> 00:11:37.250 You know, you can fix those issues, but it's hacky and not everyone will do it. 00:11:37.250 --> 00:11:40.339 So then you'll get really crappy infotainment systems, like you said, Carl. 00:11:40.339 --> 00:11:40.670 So, 00:11:41.030 --> 00:11:41.300 Carl: okay. 00:11:41.300 --> 00:11:43.160 That's probably long enough talking about activity though. 00:11:43.400 --> 00:11:47.329 Mark: So one other, one other feature that's migrated from experimental to 00:11:47.329 --> 00:11:53.983 Canary, I just saw this one a few minutes ago, is the `useEffectEvent` hook. 00:11:54.353 --> 00:11:58.253 This is something that the React team has also talked about for a while, 00:11:58.673 --> 00:12:01.763 and I actually didn't even know that any progress was being made on this 00:12:01.763 --> 00:12:03.623 until I just saw the PR announcement. 00:12:04.073 --> 00:12:05.393 I'm gonna describe this very badly. 00:12:05.393 --> 00:12:09.143 Someone should correct me on this, but it's almost like a used memo for 00:12:09.143 --> 00:12:16.258 callbacks where you'll get the latest reference to a. Callback inside when 00:12:16.258 --> 00:12:22.618 you execute it, but you get a consistent function reference back when you use it. 00:12:23.248 --> 00:12:27.718 And so this avoids the need to do a workaround where you're like, main, where 00:12:27.718 --> 00:12:33.598 the, the callback is reading something off of a ref to get the latest value. 00:12:34.198 --> 00:12:38.698 I know that this is something that had been proposed a while back and 00:12:38.698 --> 00:12:43.078 then the initial proposal got killed and they said, we'll, we'll come 00:12:43.078 --> 00:12:44.548 back and we'll rethink this later. 00:12:44.998 --> 00:12:47.878 And apparently later is finally now. 00:12:48.598 --> 00:12:49.288 Carl: Later is now. 00:12:49.288 --> 00:12:49.768 That's great. 00:12:51.028 --> 00:12:51.208 Yeah. 00:12:51.208 --> 00:12:51.598 Interesting. 00:12:51.598 --> 00:12:54.958 I'm, I'm not super up to date on this, so I'm just reading the docs 00:12:54.958 --> 00:12:56.908 right now to understand it better. 00:12:57.418 --> 00:12:58.048 Interesting. 00:12:58.048 --> 00:13:01.438 The, I definitely know that I have used refs. 00:13:01.958 --> 00:13:04.928 You know, red values off refs because of weird issues. 00:13:04.928 --> 00:13:09.608 So I'm not quite groking how this solves this immediately, but that's interesting. 00:13:09.608 --> 00:13:14.168 Mark: So, and okay, so a partial example, and again, this is me going 00:13:14.168 --> 00:13:17.108 off the top of my head and not even trying to read the post at the moment. 00:13:17.348 --> 00:13:24.668 So, if you have like a used callback that needs to access a value, you either let 00:13:24.668 --> 00:13:28.208 the callback

get recreated every time, which in case there's no point in the 00:13:28.208 --> 00:13:32.438 use callback at all, or you have the item in the dependency array, which means 00:13:32.438 --> 00:13:36.968 it's gonna, the callback is gonna get recreated still when the value changes 00:13:37.478 --> 00:13:41.768 or you don't rate it all, and oops, now you have a steel value, which is bad. 00:13:42.188 --> 00:13:42.338 Carl: Right. 00:13:42.698 --> 00:13:46.658 Mark: So what happens when you want a consistent callback reference that 00:13:46.658 --> 00:13:51.878 never changes, but it still needs to see the latest value in order to 00:13:51.878 --> 00:13:53.348 do something useful when it runs. 00:13:54.058 --> 00:14:00.298 So one workaround for this is you put a use ref a couple lines up 00:14:00.418 --> 00:14:02.968 in the component that runs first. 00:14:03.478 --> 00:14:08.188 You assign to it even in like another use effect before the one that you care about. 00:14:08.668 --> 00:14:10.288 That means it gets updated. 00:14:10.618 --> 00:14:14.368 Now you've produced this kind of weird sequence of events where I know that 00:14:14.368 --> 00:14:18.118 the ref has already been updated before the callback ends up getting run. 00:14:18.598 --> 00:14:22.798 And so part of the point of this hook is to eliminate the need to 00:14:22.798 --> 00:14:24.358 do that little dance yourself. 00:14:24.868 --> 00:14:25.258 Carl: Yeah. 00:14:25.258 --> 00:14:25.468 Okay. 00:14:25.468 --> 00:14:26.398 That makes sense. 00:14:26.518 --> 00:14:30.628 I'm reading this list of caveats and it seems tricky. 00:14:31.168 --> 00:14:35.278 The only call inside effects define it just before the effect that uses them. 00:14:35.308 --> 00:14:37.468 Do not pass them to other components or hooks. 00:14:37.978 --> 00:14:42.238 Do not use `useEffectEvent` to avoid specifying dependencies. 00:14:42.238 --> 00:14:43.048 This can hide bugs. 00:14:43.048 --> 00:14:43.408 Sure. 00:14:43.918 --> 00:14:47.698 Use it only to extract logic that does not depend on changing value. 00:14:48.238 --> 00:14:50.978 That's quite a set of constraints. 00:14:51.188 --> 00:14:55.538 Mark: When the new docs came out, and Dan and a couple others wrote the tutorial. 00:14:55.688 --> 00:14:59.558 There were a couple pages in there that actually referenced this hook 00:14:59.858 --> 00:15:03.218 as the solution for some of the problems that were being described. 00:15:03.773 --> 00:15:08.783 Even though the hook didn't exist yet, some of the docs pages also try 00:15:08.783 --> 00:15:15.443 to make the terminology very unique, where they talk about lowercase e 00:15:15.503 --> 00:15:20.393 effects as in like, you know, just the generic concept of a side effect versus 00:15:20.393 --> 00:15:27.443 a capital E effect, which is like a somehow react specific concept that I 00:15:27.443 --> 00:15:30.023 don't think the docs ever fully defined. 00:15:30.683 --> 00:15:36.803 And

so in, in a way like the use effect event hook, is the React team 00:15:36.803 --> 00:15:40.403 trained to somehow solidify this. 00:15:40.898 --> 00:15:46.148 Notional react effect term in a way. 00:15:46.538 --> 00:15:46.958 Carl: Interesting. 00:15:47.108 --> 00:15:47.558 Interesting. 00:15:47.948 --> 00:15:51.068 Mark: Alright, two other little data points and, and updates Worth noting. 00:15:51.248 --> 00:15:56.528 The React team merged a work in progress PR to the compiler to try to do and 00:15:56.528 --> 00:16:01.238 to try to automatically infer function names for things like callbacks that you 00:16:01.238 --> 00:16:05.438 pass to use effect so that you know when they show, like show up like in a stack 00:16:05.438 --> 00:16:07.958 trace, they are nicer and easier to read. 00:16:08.478 --> 00:16:12.258 And then the docs now have a page for the Eslint plugin of react hooks, 00:16:12.258 --> 00:16:15.438 including a bunch of information on all the different rules that it cover 00:16:15.888 --> 00:16:19.308 and that includes issues that'll get flagged by the compiler as well. 00:16:19.728 --> 00:16:23.958 Carl: Also, yeah, I wanna say on the compiler inferring function names like 00:16:24.468 --> 00:16:29.928 that is like one of the most quietly mind blowing things I have seen in a long time. 00:16:29.958 --> 00:16:33.738 I actually commented on the PR to ask like, what if this 00:16:33.738 --> 00:16:35.598 became a TC 39 proposal? 00:16:35.598 --> 00:16:41.418 Because this would have saved me days of effort over the life of my career. 00:16:41.418 --> 00:16:45.258 If there had been a little bit more data about what the heck is throwing 00:16:45.258 --> 00:16:48.048 an error instead of just like cannot read property of undefined. 00:16:48.618 --> 00:16:53.058 Oh thi this is quietly one of the mo going to be one of the most impactful 00:16:53.538 --> 00:16:55.338 changes in a long time I think. 00:16:55.788 --> 00:16:58.428 Mark: I have actually, even just recently in some of the Immer work 00:16:58.428 --> 00:17:02.358 that I've been doing, gone in and replaced anonymous arrow functions 00:17:02.358 --> 00:17:06.468 with a named function just to try to get a better name and a stack trace. 00:17:06.983 --> 00:17:07.463 Carl: Totally. 00:17:07.523 --> 00:17:08.513 Yeah, a hundred percent. 00:17:08.573 --> 00:17:11.873 And the annoyance of assigning an arrow function to a variable 00:17:11.873 --> 00:17:15.203 versus using a named function and how those are not the same thing. 00:17:15.653 --> 00:17:16.073 Mo: Cool. 00:17:16.133 --> 00:17:21.323 Let's move on to some React native news, which has gotten people a, a fair bit 00:17:21.323 --> 00:17:24.863 excited, which is one of the talks that was at React Universe comps that happened 00:17:24.863 --> 00:17:29.333 at the beginning of this month called React Native 1.0 is on the horizon. 00:17:29.543 --> 00:17:34.973 This is pretty exciting stuff because it's anecdotally, and I'm sure many 00:17:34.973 --> 00:17:37.073 people have had the same experience as me. 00:17:37.463 --> 00:17:41.153 One of the biggest things that people oftentimes use, which is a really, 00:17:41.153 --> 00:17:45.863 really, you know, straw man argument, but nonetheless is there, is that, oh, react 00:17:45.863 --> 00:17:47.688 native's not stable because it's not 1.0. 00:17:48.338 --> 00:17:52.088 I kid you not, when I say three weeks ago we were talking about starting a new 00:17:52.088 --> 00:17:56.438 project here at Theo and someone brought this up as a reason not to use React 00:17:56.438 --> 00:17:59.528 Native as one of like the prospective clients that we had because another 00:17:59.528 --> 00:18:03.548 company who was trying to push them to use Flutter had told them, oh, it's not stable 00:18:03.548 --> 00:18:05.733 because it's not 1.0 da da da da da. 00:18:06.488 --> 00:18:08.798 And you know, there's a little bit of fear mongering around this. 00:18:09.068 --> 00:18:12.548 The reality of it is that React Native has been around for way too long and it's been 00:18:12.548 --> 00:18:17.108 used in many, many serious production apps for, you know, several, several years now. 00:18:17.468 --> 00:18:21.008 And so I think this is something that a lot of people have discussed with the 00:18:21.008 --> 00:18:23.078 React Native Core team over the years. 00:18:23.288 --> 00:18:25.178 And you know, there's always been a bit of a reluctance on 00:18:25.178 --> 00:18:27.068 going to 1.0 for various reasons. 00:18:27.338 --> 00:18:29.348 Um, and so this talk is really interesting 'cause they talk a 00:18:29.348 --> 00:18:32.228 little bit about the history of that and what the reasons are for that. 00:18:32.558 --> 00:18:36.878 But really what's happened over the last year is that the release process for React 00:18:36.878 --> 00:18:38.648 Native has been significantly streamlined. 00:18:38.768 --> 00:18:41.168 So there are now six releases. 00:18:41.523 --> 00:18:42.813 Being targeted for every single year. 00:18:42.813 --> 00:18:46.863 So every other month there being a release from two releases, which was what we 00:18:46.863 --> 00:18:51.153 had in 2024 and you know, a lot more sporadic releases in the previous years. 00:18:51.153 --> 00:18:55.173 So there was no really never a schedule to it before where, whereas now there is 00:18:55.413 --> 00:18:58.383 one of the things that's been happening over the years, but really accelerated 00:18:58.383 --> 00:19:02.493 over the last, I'd say year, is that a lot of the APIs are being really 00:19:02.493 --> 00:19:06.183 stabilized, reduced, and the surfaces are being completely trimmed down. 00:19:06.423 --> 00:19:10.443 And so the whole idea with this is less API surfaces externally means that 00:19:10.893 --> 00:19:15.003 there's less likelihood for breaking changes in the long term, which helps 00:19:15.003 --> 00:19:18.273 them feel confident to

say, Hey, this is a 1.0 or reaching out sort 00:19:18.273 --> 00:19:21.933 of monumental point where they can actively say, Hey, this is a 1.0 release. 00:19:22.443 --> 00:19:24.513 And the other thing is that the React native. 00:19:25.013 --> 00:19:29.483 Pipelines for building React native Core was quite a manual process in the 00:19:29.483 --> 00:19:34.433 past, and so what they've done in sort of recent years is worked on introducing 00:19:34.433 --> 00:19:38.753 a lot more end-to-end testing, some workflows that would test our C bugs and 00:19:38.753 --> 00:19:40.703 you know, breaking changes much quicker. 00:19:40.703 --> 00:19:44.243 And so that's really been a lot of the efforts behind the scenes, 00:19:44.243 --> 00:19:46.823 which you won't see in features and functionalities, but it's really been to 00:19:46.823 --> 00:19:48.323 the workflow for building React native. 00:19:48.653 --> 00:19:52.523 And so a lot of this is really moving us towards that direction 00:19:52.523 --> 00:19:53.753 where there can be at 1.0. 00:19:54.143 --> 00:19:55.793 And so the conversation isn't. 00:19:56.183 --> 00:19:59.213 Potentially, hey, there's gonna be a 1.0 in the next few months. 00:19:59.483 --> 00:20:03.083 Maybe not even in the next year, but it is somewhere there where they're 00:20:03.083 --> 00:20:07.373 feeling like, okay, we can go ahead to, to basically releasing a 1.0 for React 00:20:07.373 --> 00:20:09.233 native at some point in the near future. 00:20:09.233 --> 00:20:11.933 So the React team's gonna be, the React native team is gonna be working on this 00:20:11.933 --> 00:20:15.863 quite extensively and trying to reach a point where they're happy and so 00:20:15.863 --> 00:20:18.623 they're gonna be working with a bunch of people to start to potentially put 00:20:18.623 --> 00:20:19.943 a date on it, which is very exciting. 00:20:20.273 --> 00:20:21.023 Carl: That is really exciting. 00:20:21.113 --> 00:20:22.853 That's a long time towards 1.0. 00:20:22.853 --> 00:20:27.683 But like it would've felt premature I think for them to get, to call 00:20:27.683 --> 00:20:30.563 it a 1.0 before, or at least they would've had to do a lot of breaking. 00:20:30.863 --> 00:20:33.233 Mark: Even just waiting for the new architecture to be the 00:20:33.263 --> 00:20:34.643 default, I think was a big thing. 00:20:36.023 --> 00:20:36.113 Mm-hmm. 00:20:36.353 --> 00:20:36.373 Yeah, definitely. 00:20:36.653 --> 00:20:36.983 Carl: Yeah. 00:20:37.043 --> 00:20:40.583 And that really seems like it was a meaningful, a meaningful reason 00:20:40.613 --> 00:20:44.483 to delay, like it was such a large disruption to so many different parts 00:20:44.483 --> 00:20:46.883 of the ecosystem, but also so essential. 00:20:47.213 --> 00:20:50.603 Yeah, it feels more truly native under the new architecture, rather 00:20:50.603 --> 00:20:55.223 than having to like serialize between two independent systems. 00:20:55.658 --> 00:20:59.408 It kind of reminds me of like when Docker launched because it was a Linux 00:20:59.408 --> 00:21:01.778 feature, you know, a Linux kernel feature. 00:21:02.048 --> 00:21:05.558 I remember for years they had like a, if you wanted to use it on Mac, you 00:21:05.558 --> 00:21:08.648 had to technically run a vm, which introduced all sorts of weirdness. 00:21:09.038 --> 00:21:12.908 And so that feels, I dunno, this feels technically similar to me in how they 00:21:12.908 --> 00:21:16.448 like figured out how to not have two independent systems communicating 00:21:17.018 --> 00:21:18.548 with each other in that kind of way. 00:21:18.548 --> 00:21:22.058 And now that they've cleared that hurdle, they can get towards 00:21:22.058 --> 00:21:23.498 a greater level of stability. 00:21:24.038 --> 00:21:24.428 Cool. 00:21:24.728 --> 00:21:25.088 Awesome. 00:21:25.688 --> 00:21:29.018 Mark: One other thing that actually kinda reminds me of, so we had squiggle conf a 00:21:29.108 --> 00:21:33.158 week and a half ago and one of the talks was from Shelley Vohr, who's part of the 00:21:33.158 --> 00:21:39.188 Electron core team and she did a talk about automating systems and you know, 00:21:39.188 --> 00:21:44.198 things like security and repeatability and what happens if the system goes down. 00:21:44.768 --> 00:21:49.358 And it sounds like a lot of the effort that's been involved on the RN side really 00:21:49.358 --> 00:21:55.058 is about CI pipelines and automation and turning a manual release process 00:21:55.058 --> 00:21:57.008 into an automated release process. 00:21:57.458 --> 00:22:01.538 And you know, having that consistency is a pretty big deal here. 00:22:02.013 --> 00:22:02.493 Carl: Cool. 00:22:02.793 --> 00:22:03.753 Drama post? 00:22:04.233 --> 00:22:05.073 Mark: Drama post. 00:22:05.673 --> 00:22:10.323 Carl: Yeah, so there was a recent post called React Won by default and 00:22:10.323 --> 00:22:12.663 it's killing front end innovation. 00:22:13.023 --> 00:22:13.653 Mark: To some extent. 00:22:13.653 --> 00:22:15.363 There's nothing new in this post. 00:22:15.423 --> 00:22:17.823 People have been making complaints about this for years. 00:22:18.003 --> 00:22:21.603 It's a pretty well written post, and it did make all the rounds 00:22:21.603 --> 00:22:26.553 and spawned massive 800 comment, hacker news thread and responses on 00:22:26.553 --> 00:22:27.963 Twitter and a bunch of other places. 00:22:28.383 --> 00:22:35.253 The first argument is that React itself has kind of stagnated that it was a 00:22:35.253 --> 00:22:40.563 big deal in 2013 when the virtual do solved problems with Angular, but that 00:22:40.773 --> 00:22:46.173 React really hasn't innovated since then claim, and that things like the React 00:22:46.173 --> 00:22:48.423 compiler are a bit more of a bandaid. 00:22:48.808 --> 00:22:53.848 Whereas other frameworks like solid and spelt and quick are doing new 00:22:53.848 --> 00:22:58.888

and innovative things around signals and ruins and resum ability and 00:22:59.038 --> 00:23:01.408 other approaches to updating the dom. 00:23:01.558 --> 00:23:03.298 But the rest of the argument is that. 00:23:04.418 --> 00:23:07.838 The typical discussion these days for a project is, okay, 00:23:07.868 --> 00:23:09.458 which framework should we use? 00:23:09.908 --> 00:23:16.028 Well, let's use React because it has the biggest ecosystem, because there's 00:23:16.028 --> 00:23:21.368 the most developers available because AI are familiar with it, because there's 00:23:21.368 --> 00:23:24.068 lots of libraries out there, et cetera. 00:23:24.488 --> 00:23:29.618 And the phrase that always comes to mind and for me is the old one about no one 00:23:29.618 --> 00:23:35.468 ever got fired for choosing IBM that back in the day, like IBM was the safe choice 00:23:35.468 --> 00:23:39.158 for, you know what, whatever tools it is sort of that same principle today. 00:23:39.188 --> 00:23:43.268 Like most people are not generally choosing React. 00:23:43.838 --> 00:23:49.178 Because they're specifically excited about suspense or transitions 00:23:49.178 --> 00:23:50.948 or other things like that. 00:23:50.948 --> 00:23:54.248 It's the industry standard, so we'll stick with that. 00:23:54.758 --> 00:23:59.348 And so the article argues that because of that, because the mindset 00:23:59.348 --> 00:24:04.358 is used, react by default, that it's sort of choking out other frameworks 00:24:04.358 --> 00:24:08.378 that have had more innovation and newer interesting approaches. 00:24:08.738 --> 00:24:13.388 And so it ends up offering some suggestions for things to evaluate 00:24:13.388 --> 00:24:16.658 about scaling and performance and team skills and whatnot. 00:24:16.928 --> 00:24:20.558 And then tries to counter argue the typical like size 00:24:20.558 --> 00:24:22.358 of the ecosystem type points. 00:24:22.748 --> 00:24:26.228 It's a well-written article, like it's not flame bait. 00:24:26.228 --> 00:24:31.058 The title is is well out there, but it makes a pretty good actual point and it 00:24:31.058 --> 00:24:34.298 spawned a lot of discussion, like I said, hacker News and a bunch of other places. 00:24:34.688 --> 00:24:38.318 But I think the really interesting counterpoint to all that. 00:24:38.813 --> 00:24:43.913 Is Rick Hanlon from the React team put up a very long thread on Blue 00:24:43.913 --> 00:24:49.073 Sky, which really should be its own blog post at this point where he 00:24:49.073 --> 00:24:54.833 says that all the frameworks know how to update the do efficiently React 00:24:54.833 --> 00:24:59.333 has innovated in the past, but it's also, it was so good in the past. 00:24:59.723 --> 00:25:03.143 People are actually kind of ignoring the innovations they've done since 00:25:03.203 --> 00:25:08.423 2017 and 2018, and that reacts focus for the last seven years has been 00:25:08.423 --> 00:25:13.553 not about how can we make Dom updates faster per se, but about scheduling. 00:25:14.048 --> 00:25:19.718 Things like concurrent mode, transitions, suspense, even the new activity component 00:25:19.898 --> 00:25:23.768 builds off of the foundations that they've built for the last several years. 00:25:23.768 --> 00:25:23.828 Yeah. 00:25:24.368 --> 00:25:28.958 And so his argument is that number one, when people say react is an 00:25:28.958 --> 00:25:33.248 innovating, they're ignoring all the new features built around concurrency. 00:25:33.848 --> 00:25:40.358 And number two, that most people are still thinking about using React in 00:25:40.358 --> 00:25:44.228 a very 20 16, 20 17 ish sort of way. 00:25:44.798 --> 00:25:48.938 Most people aren't even thinking about using the new capabilities 00:25:48.938 --> 00:25:50.078 that React has unlocked. 00:25:50.888 --> 00:25:52.298 I think he's actually got a pretty good point. 00:25:52.823 --> 00:25:53.363 Carl: That's fair. 00:25:53.543 --> 00:25:57.533 I would generally agree with that and like I am very much in that boat, 00:25:57.593 --> 00:26:02.093 I'll be honest, like I haven't written extensive from scratch, like build an 00:26:02.093 --> 00:26:04.613 app and react since about that time. 00:26:04.613 --> 00:26:08.603 The last time I really did that from scratch to like a full production 00:26:08.603 --> 00:26:13.103 level where I was like exclusively focused on the front end was about 00:26:13.103 --> 00:26:15.233 that time, like ended around 2021. 00:26:15.833 --> 00:26:18.773 So I've been following a lot of this, but I haven't used it at the 00:26:18.773 --> 00:26:20.783 same level of depth that I used to. 00:26:21.293 --> 00:26:24.653 I have seen somebody who, you know, one of my internet acquaintances 00:26:24.953 --> 00:26:28.043 who I have a lot of respect for, as you know, both technically and 00:26:28.043 --> 00:26:29.363 like entrepreneurial and whatever. 00:26:29.873 --> 00:26:34.973 He's been extolling the virtues of server components for the last couple 00:26:34.973 --> 00:26:38.753 of months, I think, and it's been on my, you know, it's been somewhere on 00:26:38.753 --> 00:26:40.313 my to-do list to talk more with him. 00:26:40.363 --> 00:26:41.293 Mark: Daniel Switz. 00:26:41.653 --> 00:26:42.013 Carl: Yep, yep. 00:26:42.013 --> 00:26:42.653 Daniel Switz. 00:26:43.003 --> 00:26:44.773 Just like I've heard him say some things. 00:26:44.773 --> 00:26:48.073 It's like, okay, I feel like you get it and I feel like you get it 00:26:48.073 --> 00:26:49.243 in a way that you could communicate. 00:26:49.698 --> 00:26:53.598 It's crossed my mind actually to have him and Ricky and or him and Dan or 00:26:53.598 --> 00:26:56.898 I don't know, a group of people on a stage like this and just like talk 00:26:56.898 --> 00:26:57.918 about it and be like, what the fuck? 00:26:58.098 --> 00:26:58.548 What are we doing? 00:26:58.758 --> 00:26:59.328 How do you do this? 00:26:59.958

--> 00:27:00.918 So yeah, I don't know. 00:27:00.918 --> 00:27:04.638 It's like, it's definitely there is innovation happening. 00:27:05.148 --> 00:27:09.288 I think a lot of the innovation, like there's innovation happening and there's 00:27:09.288 --> 00:27:11.088 also just like roadblock clearing. 00:27:11.268 --> 00:27:15.468 It's like, you know, there's the innovative, you build the road, but then 00:27:15.468 --> 00:27:16.578 you have to deal with the consequences. 00:27:16.578 --> 00:27:17.898 Like, great, you have this road. 00:27:17.898 --> 00:27:19.458 Like what is it like to actually use it? 00:27:20.088 --> 00:27:24.438 And then a lot of the time you realize there are speed bumps and 00:27:24.438 --> 00:27:27.618 whatever that you didn't realize you were building in the first place. 00:27:28.128 --> 00:27:29.808 And the fix there is not innovate. 00:27:29.808 --> 00:27:31.878 You don't just like, well that sucked. 00:27:31.878 --> 00:27:32.778 Let's build a new road. 00:27:33.078 --> 00:27:33.858 No, you fix it. 00:27:33.888 --> 00:27:37.938 Figure out different ways to approach the same problem that 00:27:37.938 --> 00:27:39.738 have a different set of trade-offs. 00:27:39.918 --> 00:27:43.308 And so I think that's some of what's being complained about here is that like 00:27:43.308 --> 00:27:45.318 people are like, we need a new thing. 00:27:45.318 --> 00:27:46.758 We need to rewrite from scratch. 00:27:47.518 --> 00:27:49.138 And No, we don't. 00:27:49.678 --> 00:27:50.218 I don't think we do. 00:27:51.688 --> 00:27:52.438 So, yeah, I don't know. 00:27:52.438 --> 00:27:53.818 I guess that's what I, what I have to say there. 00:27:54.328 --> 00:27:58.048 Mark: So, sort of on on that note, Ryan Carniato from the solid team 00:27:58.078 --> 00:28:01.408 routinely does streams where he talks about what he's working on or 00:28:01.468 --> 00:28:02.908 you, where the ecosystem is going. 00:28:03.238 --> 00:28:07.438 He and Ricky have had a number of like, actually. 00:28:08.008 --> 00:28:11.908 Intentional and productive discussions back and forth on Blue Sky and Twitter 00:28:12.328 --> 00:28:16.108 where Ryan has said, we've got our own version of suspense, we've got 00:28:16.108 --> 00:28:17.458 our own version of transitions. 00:28:17.458 --> 00:28:18.778 We're trying to do things this way. 00:28:19.258 --> 00:28:22.798 And Ricky has put up a demo and said, how does this, here's 00:28:22.798 --> 00:28:23.878 the React way to do this. 00:28:23.878 --> 00:28:25.888 How's this compare to the way you guys are doing it? 00:28:26.398 --> 00:28:32.938 And so Ricky was actually just on Ryan Carniatos stream on Friday and I 00:28:32.938 --> 00:28:34.888 looked, and it's a six hour long video. 00:28:34.978 --> 00:28:37.978 No, I most definitely did not watch the video. 00:28:38.248 --> 00:28:41.668 I cheated and used a summarizing tool to try to gimme a sense of what 00:28:41.668 --> 00:28:43.138 they were

actually talking about. 00:28:43.378 --> 00:28:48.538 But it looked like they talked about where React has gone and what 00:28:48.538 --> 00:28:52.138 has changed with all the different concurrency related features. 00:28:52.498 --> 00:28:57.208 And then I think they tried to take a sort of a classic react. 00:28:57.268 --> 00:29:00.838 I think it was like a React 17 to do application, and then they 00:29:00.838 --> 00:29:05.668 updated it live on stream to use all the modern latest React features. 00:29:06.148 --> 00:29:10.558 So if you want to watch them talking about this for six hours, the video's there. 00:29:10.948 --> 00:29:16.018 But it's a good example of people who know how this, how these technologies 00:29:16.018 --> 00:29:21.268 are implemented, discussing them as well as Ricky demoing how you could 00:29:21.268 --> 00:29:23.068 actually use these in an application. 00:29:23.338 --> 00:29:23.608 Carl: Yeah. 00:29:23.608 --> 00:29:26.878 I will say, going back to a point a little bit about, you know, you 00:29:26.878 --> 00:29:30.208 shared the long thread and made an offhand comment about like, this could 00:29:30.208 --> 00:29:31.648 really be a blog post at this point. 00:29:31.648 --> 00:29:36.748 Like the post on Ricky's feed right before that is the, if you all promise not to 00:29:36.748 --> 00:29:40.208 ask me for docs or blog posts, maybe I'll explain a bit about why creating a cache 00:29:40.228 --> 00:29:44.698 API for suspense is so hard and it's, oh, I love that you're doing all of this, like 00:29:44.698 --> 00:29:49.138 social media outreach and everything, but like part of the problem that, part of the 00:29:49.138 --> 00:29:52.108 reason why nobody understands all of this and you have to do all the social media 00:29:52.108 --> 00:29:55.408 outreach is because there aren't static available resources for people to read. 00:29:55.408 --> 00:29:59.308 So it's like, ah, I love that this is happening and it's so good and so helpful. 00:29:59.808 --> 00:30:01.968 And there's follow up that's not happening that I think is 00:30:01.968 --> 00:30:03.048 really crucially important. 00:30:03.438 --> 00:30:06.228 Mark: That's actually been one of my running frustrations 00:30:06.228 --> 00:30:07.338 and complaints for a while. 00:30:07.398 --> 00:30:10.128 Ricky and I have actually had some back and forth on this, 00:30:10.128 --> 00:30:11.778 multiple times on Blue Sky. 00:30:12.348 --> 00:30:12.408 Yeah. 00:30:12.408 --> 00:30:15.348 Admittedly, I'm also not sitting here, honestly. 00:30:15.348 --> 00:30:17.598 I should probably start watching the docs repos so I have a better 00:30:17.598 --> 00:30:19.098 sense of what updates do happen. 00:30:19.368 --> 00:30:23.268 That one's on me, but to a certain extent, my, my knowledge of what's 00:30:23.268 --> 00:30:25.008 in the docs can get a little stale. 00:30:25.008 --> 00:30:25.098 Right. 00:30:25.578 --> 00:30:28.998 But Ricky has repeatedly complained that. 00:30:29.503 --> 00:30:33.883 People keep making the same wrong assumptions about what React 00:30:33.943 --> 00:30:38.263 has available, why the React team is doing things, et cetera. 00:30:38.773 --> 00:30:43.183 I've pushed them multiple times this year and said, you know, my 00:30:43.183 --> 00:30:46.153 answer is go write a docs page. 00:30:46.603 --> 00:30:46.693 Yeah. 00:30:46.693 --> 00:30:51.913 That covers exactly the topic you want and to have answered, and 00:30:51.913 --> 00:30:55.273 it answers it in exactly the way you want This material covered. 00:30:55.783 --> 00:30:59.623 A lot of people are still not gonna read that docs page, but some people who are 00:30:59.623 --> 00:31:01.783 already looking at the docs will see it. 00:31:02.293 --> 00:31:07.663 And when you run into yet another one of these questions on social media, now you 00:31:07.663 --> 00:31:12.823 have the pre-written answer and you link to it rather than having to answer it 00:31:12.823 --> 00:31:17.743 from scratch every time you see the same misconception pop up on social media. 00:31:18.013 --> 00:31:22.363 I, I wanna be clear, I, I am genuinely excited that Ricky has done so much 00:31:22.363 --> 00:31:24.373 outreach over the last year or so. 00:31:25.158 --> 00:31:29.208 Even just in the last couple weeks he was, he wrote dozens of tweets 00:31:29.268 --> 00:31:34.668 on both Blue Sky and Twitter around the threads related to the React 00:31:34.698 --> 00:31:37.098 innovation by default discussion. 00:31:37.608 --> 00:31:40.458 And I'm genuinely happy he's doing this much outreach. 00:31:40.518 --> 00:31:43.368 It's sort of taking Dan's place in that sense. 00:31:43.878 --> 00:31:49.428 But when your great answers are buried, 15 replies deep in a Twitter 00:31:49.428 --> 00:31:53.688 thread, no one sees them other than the person you're responding to. 00:31:54.198 --> 00:31:58.758 And that is the kind of material that desperately ought to be its 00:31:58.758 --> 00:32:03.348 own blog post, as well as these couple top level threats as well. 00:32:03.348 --> 00:32:05.838 And so I genuinely happy he's engaging. 00:32:05.838 --> 00:32:08.718 I would just love to see that material written up longer term. 00:32:09.448 --> 00:32:12.718 Carl: This is clearly a bit of a cycle, you know, like social, this 00:32:12.718 --> 00:32:14.668 has been true for years generally. 00:32:15.028 --> 00:32:21.023 So like maybe this is an opportunity for someone here listening to go through 00:32:21.173 --> 00:32:24.028 some of the, to go through these threads. 00:32:24.028 --> 00:32:28.198 Like if you're champing at the bit for an opportunity to have an impact on the 00:32:28.198 --> 00:32:32.278 ecosystem and on the industry, like this could be a pretty achievable way to do so. 00:32:32.278 --> 00:32:37.648 Like this content is out there, it exists, but not in a way that's discoverable. 00:32:37.648 --> 00:32:42.418 So like taking

this knowledge that is being produced in ephemeral social 00:32:42.418 --> 00:32:47.488 media threads and then just like restructuring it, reformatting it into 00:32:47.488 --> 00:32:52.378 a markdown document and submitting a PR to react could be really effective. 00:32:52.438 --> 00:32:55.588 I, I'll throw that gauntlet down, like that is an achievable thing 00:32:56.158 --> 00:32:57.538 that I am probably not gonna do. 00:32:58.018 --> 00:33:01.328 Mark: People used to say that the real React docs was Dan Abramov's 00:33:01.348 --> 00:33:05.248 Twitter account, which he then deleted and all that info is gone. 00:33:05.488 --> 00:33:09.568 I don't expect blue sky to go down, but yeah, like if someone out there 00:33:09.928 --> 00:33:14.098 wanted to go through some of, you know, Dan and Ricky and whoever else's 00:33:14.128 --> 00:33:18.718 Blue Sky threads and pull out info and submit docs, prs like that would 00:33:18.718 --> 00:33:20.308 genuinely help the entire ecosystem. 00:33:20.668 --> 00:33:20.908 Carl: Yep. 00:33:21.148 --> 00:33:21.538 Right. 00:33:21.598 --> 00:33:22.948 And it doesn't need to be perfect first. 00:33:22.948 --> 00:33:24.058 Drafts are so good. 00:33:24.658 --> 00:33:27.928 First, the first draft is so hard and going from first draft to published 00:33:27.928 --> 00:33:29.578 thing is still a lot of work. 00:33:29.938 --> 00:33:33.058 But man, just getting a first draft out is often the thing that tips it 00:33:33.058 --> 00:33:34.588 over the edge into actually happening. 00:33:35.098 --> 00:33:35.398 Yep. 00:33:35.403 --> 00:33:37.768 I'll just say that if anyone's looking for something. 00:33:38.398 --> 00:33:39.028 Mark: Love the idea. 00:33:39.328 --> 00:33:40.888 Alright, moving right along. 00:33:41.158 --> 00:33:44.278 A few different updates related to server components this month. 00:33:44.308 --> 00:33:49.588 The biggest would be that React Router now has RSC support in 00:33:49.588 --> 00:33:51.898 their framework mode builds. 00:33:52.048 --> 00:33:55.528 So React Router, as I understand it now, has three different modes. 00:33:55.888 --> 00:34:00.178 There's sort of the, the traditional client side only, here's your list of 00:34:00.178 --> 00:34:05.548 routes mode, there's a somewhat more complicated data mode, and then there's 00:34:05.548 --> 00:34:08.908 the full blown full build framework mode. 00:34:09.208 --> 00:34:13.408 And so I believe they previously announced some RSC primitives 00:34:13.408 --> 00:34:15.028 available in data mode. 00:34:15.538 --> 00:34:18.388 And then I believe the framework mode is now taking those and 00:34:18.388 --> 00:34:22.318 expanding on them somehow to make it available for the full build. 00:34:22.828 --> 00:34:28.198 So, you know, again, having more RSC options available besides 00:34:28.198 --> 00:34:30.658 just next is a pretty big deal. 00:34:30.658 --> 00:34:34.288 And especially when it's built into something as widely used as React router. 00:34:34.783 --> 00:34:35.083 Carl: Yep. 00:34:35.323 --> 00:34:35.803 Love that. 00:34:36.193 --> 00:34:39.583 Mark: They also announced that React router now has stable 00:34:39.583 --> 00:34:41.863 middleware support as well. 00:34:42.103 --> 00:34:43.993 Your routes can now have middleware. 00:34:44.473 --> 00:34:49.033 Krasimir Tsonev, who is a React educator and has been around for a 00:34:49.033 --> 00:34:54.373 while, put up a nifty little support matrix called, can I use RSC today, 00:34:54.823 --> 00:35:00.643 where he tried to do equivalent bits of RSC usage and features across several 00:35:00.643 --> 00:35:07.063 different tools from next in, in Remix and Waku and various other tools. 00:35:07.543 --> 00:35:08.743 He was also very curious. 00:35:08.743 --> 00:35:12.343 I, I actually talked to him at React Summit in, in June, 00:35:12.343 --> 00:35:13.123 and I think this is what. 00:35:13.723 --> 00:35:17.323 And he was talking to a couple other folks, and I think this is what spawned 00:35:17.323 --> 00:35:21.913 him doing that deep dive where he was actually kind of bothered by the fact that 00:35:21.913 --> 00:35:23.743 server components require a framework. 00:35:24.133 --> 00:35:27.943 And so he went off and ended up implementing his own tool called for cat. 00:35:28.798 --> 00:35:33.778 Which is supposed to be somehow a proof of concept for using an RFC 00:35:33.808 --> 00:35:37.408 without an actual framework per se. 00:35:37.768 --> 00:35:43.468 So sort of a more primitive, granular client server separation build tool. 00:35:43.948 --> 00:35:48.808 Speaking of build tools, I saw mention that there is a set of plugins available 00:35:48.808 --> 00:35:54.538 that try to add some RSC support to the RS build, rust based bundler as well. 00:35:55.553 --> 00:35:59.843 Finally, I also saw a good blog post that talked about techniques for doing parallel 00:35:59.843 --> 00:36:03.263 and recursive route rendering with RSCs. 00:36:03.653 --> 00:36:06.083 As Carl mentioned earlier, all this stuff is frankly outside of my 00:36:06.083 --> 00:36:10.313 experience, I've never tried to render, you know, RSCs much less do parallel 00:36:10.313 --> 00:36:13.673 and recursive stuff, but it clearly, people are out there experimenting 00:36:13.673 --> 00:36:14.723 with these things and that's good. 00:36:15.233 --> 00:36:15.833 Carl: Oh man. 00:36:15.953 --> 00:36:18.533 I'm looking at the blog post. 00:36:18.533 --> 00:36:20.873 You mentioned React server components without a framework 00:36:20.903 --> 00:36:22.643 and it's got a mention of Flux. 00:36:22.853 --> 00:36:24.233 Oh, throwback. 00:36:24.503 --> 00:36:24.803 Yeah. 00:36:24.833 --> 00:36:29.423 I mean we're Reactiflux because for about a six or eight months it was React 00:36:29.423 --> 00:36:33.383 and then you pair it with Flux and that was how you do UI and state management. 00:36:33.383 --> 00:36:34.673 So it's wow,

throwback. 00:36:34.703 --> 00:36:35.273 That's a long time. 00:36:35.753 --> 00:36:37.763 Alright, little bit of a roundup on. 00:36:38.323 --> 00:36:41.893 Vulnerabilities and security incidents on MPM. 00:36:42.283 --> 00:36:43.603 There's been a lot this month. 00:36:44.053 --> 00:36:47.143 Mark: I think that the first one happened late last month, 00:36:47.143 --> 00:36:48.703 and we mentioned it briefly. 00:36:48.703 --> 00:36:48.763 Yeah. 00:36:48.763 --> 00:36:52.933 And then there was just like this constant flood of new compromises, 00:36:52.933 --> 00:36:56.383 new vulnerabilities, all kinds of packages being taken over, 00:36:56.713 --> 00:37:02.023 ranging from crypto miners to like full-blown credential stealing. 00:37:02.023 --> 00:37:04.063 It's, it's been pretty bad out there folks. 00:37:04.603 --> 00:37:04.933 Carl: Right? 00:37:04.933 --> 00:37:06.133 So last month. 00:37:06.838 --> 00:37:11.098 NX was compromised, which is discussed in this set of links that we have here. 00:37:11.368 --> 00:37:16.108 I'll send one at a time as we get into it, but yeah, so it, what we've seen 00:37:16.108 --> 00:37:23.158 has been everything from like pretty, there was a targeted attack that would 00:37:23.398 --> 00:37:29.368 do like intercede, crypto payments and sub out addresses for, you know, an 00:37:29.368 --> 00:37:33.713 attacker's wallet actually that had a small innovation in that category of 00:37:33.713 --> 00:37:37.433 attack where it would generate an address that was visually similar to the one 00:37:37.433 --> 00:37:39.443 that you had used to try and escape. 00:37:39.443 --> 00:37:44.633 Notice I heard that attack only got like $50 or like less than $500. 00:37:44.633 --> 00:37:47.393 I've seen some conflicting numbers, but like generally not effective, 00:37:47.453 --> 00:37:49.643 did not achieve its goals. 00:37:50.183 --> 00:37:52.223 But like it hit debug. 00:37:52.223 --> 00:37:55.613 Like it hit a package that I saw the security alert go out 00:37:55.613 --> 00:37:57.593 and I was like, oh, that sounds like something that I might use. 00:37:57.863 --> 00:37:58.343 And I checked. 00:37:58.343 --> 00:38:03.203 I'm like, yep, a bunch of projects on my computer were using that package. 00:38:03.593 --> 00:38:09.443 That was the one that got targeted with crypto interception, but previously, 00:38:09.533 --> 00:38:14.063 I think it was nx, was it last month, that we had the people who were stealing 00:38:14.063 --> 00:38:19.403 credentials and using AI to generate other code to steal credentials. 00:38:19.403 --> 00:38:22.793 Like, ah, that's the worst attack I've ever seen. 00:38:23.263 --> 00:38:26.743 And the only reason it wasn't worse was because of the 00:38:26.743 --> 00:38:28.573 limited scope of compromise. 00:38:28.903 --> 00:38:33.823 So like I was primed seeing that innovative, highly effective attack 00:38:34.003 --> 00:38:40.063 when I saw this massively widely distributed

compromise of debug. 00:38:40.783 --> 00:38:45.283 And I have a little bit of egg on my face regarding this because I had pinged 00:38:45.283 --> 00:38:49.393 in the node Discord that I help operate saying like, oh, you need to look at this. 00:38:49.393 --> 00:38:50.263 This is awful. 00:38:50.263 --> 00:38:52.783 And it ended up not being as bad as I thought because that was a crypto 00:38:52.783 --> 00:38:54.353 miner, not a credential stealer. 00:38:54.763 --> 00:38:58.063 Mark: The attack itself seemed like a pretty big deal, and then it was 00:38:58.063 --> 00:39:03.793 almost sort of wasted on, well, it has to lead to you accidentally 00:39:03.793 --> 00:39:08.383 build a client side app that has the compromised version built into it. 00:39:08.803 --> 00:39:11.953 Carl: Right, they managed to successfully target one of the 00:39:11.953 --> 00:39:14.383 single most widely used packages. 00:39:14.803 --> 00:39:19.273 And completely squandered it by using it to execute an attack that 00:39:19.273 --> 00:39:22.813 had such limited application that they just didn't get anything. 00:39:23.113 --> 00:39:28.813 So like that's just straight up, like they screwed up, like they 00:39:28.813 --> 00:39:32.713 achieved a massive level of success and just like immediately fell on 00:39:32.713 --> 00:39:34.223 their face and did nothing with it. 00:39:34.303 --> 00:39:35.233 That's just a miss. 00:39:35.233 --> 00:39:38.143 Like that was just luck, that it wasn't worse than it was. 00:39:38.773 --> 00:39:41.443 Mark: But on the, on the flip side, the article that's talking about the 00:39:41.443 --> 00:39:46.183 ongoing supply chain attack did do a bunch of credential stealing, targeting 00:39:46.183 --> 00:39:50.563 a bunch of packages like tiny color and a bunch of CrowdStrike packages. 00:39:51.043 --> 00:39:51.103 Yeah. 00:39:51.103 --> 00:39:56.593 I don't know the extent of like what sites got hit because of that compromise. 00:39:57.073 --> 00:39:57.253 Yeah. 00:39:57.283 --> 00:40:01.243 But I believe that one's, that one had did a, done a pretty good job of finding 00:40:01.243 --> 00:40:06.523 credentials and publishing them on either, I think it was like either creating 00:40:06.523 --> 00:40:11.863 a new GitHub repo or creating a new specially named branch in GitHub repos 00:40:12.223 --> 00:40:14.473 to try to exfiltrate the credentials. 00:40:14.983 --> 00:40:15.343 Carl: Yeah. 00:40:15.403 --> 00:40:16.933 Oh, I was just reading this one actually. 00:40:16.933 --> 00:40:21.793 It was, they had, they, somebody had added a line to the GitHub action that 00:40:21.793 --> 00:40:27.583 did, that would echo out the title of the PR and because it just did an un 00:40:27.583 --> 00:40:29.413 escaped string, you know, echo this. 00:40:29.413 --> 00:40:31.813 You could just terminate that and then run whatever you wanted. 00:40:32.368 --> 00:40:37.228 On the GitHub action, like, do not let any arbitrary person run whatever 00:40:37.228 --> 00:40:38.518 script they want in your seat. 00:40:38.878 --> 00:40:40.948 Like, oh man, that it's, that's pretty bad. 00:40:41.488 --> 00:40:43.468 And also, oof, this is CrowdStrike. 00:40:43.618 --> 00:40:47.128 Like, remember CrowdStrike and how they took down like every, like air 00:40:47.128 --> 00:40:51.958 travel around the world from another security problem that they had, and 00:40:51.988 --> 00:40:55.888 oops, they're a cybersecurity company where preventing attacks is their job. 00:40:56.248 --> 00:40:56.668 Oops. 00:40:56.998 --> 00:40:57.358 Yeah. 00:40:57.628 --> 00:40:59.968 I don't understand how they're still operating successfully. 00:41:01.078 --> 00:41:06.448 Mark: So, GitHub and NPM did actually put up a, a, an announcement saying 00:41:06.448 --> 00:41:09.838 that they're gonna be doing a lot of work to try to tighten up. 00:41:10.608 --> 00:41:15.858 Publishing of packages down the road, they're gonna be making changes 00:41:15.858 --> 00:41:20.238 to two fa it says they're gonna deprecate time-based passwords. 00:41:20.568 --> 00:41:22.908 That sounds like it's gonna end up being a, a big deal. 00:41:23.028 --> 00:41:25.068 I don't fully understand the implications yet. 00:41:25.073 --> 00:41:28.548 And, and they said they're gonna, you know, take time to roll these changes out. 00:41:28.998 --> 00:41:30.893 But that one seems like a big deal. 00:41:31.103 --> 00:41:37.458 We're also making and trying to apply more limits to tokens and work on better 00:41:37.458 --> 00:41:40.188 trusted pet publishing workflows as well. 00:41:40.548 --> 00:41:40.998 Interesting. 00:41:41.058 --> 00:41:41.358 Carl: Yeah. 00:41:41.418 --> 00:41:44.448 That's all important and useful, but like also, I don't know if 00:41:44.448 --> 00:41:47.418 there, if you just, if somebody opens a PR to your CI, that adds. 00:41:48.118 --> 00:41:50.188 A vulnerable un escaped string. 00:41:50.188 --> 00:41:53.908 Like it doesn't really matter how, what your authentication or publishing 00:41:53.908 --> 00:41:55.678 workflow looks like if that gets merged. 00:41:55.678 --> 00:41:56.488 Like you're vulnerable. 00:41:56.488 --> 00:41:59.158 So dunno how, dunno what you do about that specifically. 00:41:59.218 --> 00:42:00.268 But, okay. 00:42:00.358 --> 00:42:02.878 Let's hop into our lightning round. 00:42:03.178 --> 00:42:07.168 Mark: I love a good article that just goes into absurd amounts of detail on a 00:42:07.168 --> 00:42:10.978 ridiculous thing that someone's trying to do, but they commit to the bit fully. 00:42:11.368 --> 00:42:18.538 And this one was, someone had a. JavaScript based game and they ported 00:42:18.538 --> 00:42:21.268 it all the way back to work on dos. 00:42:21.778 --> 00:42:25.498 Like why would you want to, I don't know, but apparently they actually 00:42:25.498 --> 00:42:27.388 made this work and I love it. 00:42:27.868 --> 00:42:33.148 Carl: That is insanity, and I

also love it spiritually similar to Doom running 00:42:33.148 --> 00:42:34.948 in TypeScript types, just for no reason. 00:42:35.518 --> 00:42:35.668 Yep. 00:42:35.668 --> 00:42:35.678 Love. 00:42:35.963 --> 00:42:40.673 Mark: CloudFlare got into the news this month because they had a dashboard 00:42:40.673 --> 00:42:46.223 failure that cascaded, and believe it or not, it was caused by manually 00:42:46.223 --> 00:42:51.983 fetching data in a use effect that went into an infinite loop, which also 00:42:51.983 --> 00:42:55.223 means they weren't actually using like React query or anything like that. 00:42:55.733 --> 00:42:56.243 Oops. 00:42:56.693 --> 00:42:59.723 Carl: Yeah, I did hear like none of their services were affected. 00:42:59.723 --> 00:43:03.983 It was just the control panels that was taken down, so that's good. 00:43:04.253 --> 00:43:09.113 I also saw Guillermo Roush throwing some shade at the CloudFlare CEO after that. 00:43:09.113 --> 00:43:10.523 So, you know, drama post. 00:43:11.093 --> 00:43:13.083 There's a cute post from Bocoup. 00:43:13.168 --> 00:43:18.053 There are web consultancy that's had a, a big impact on standards and 00:43:18.263 --> 00:43:20.813 web platform implementation details. 00:43:21.143 --> 00:43:24.893 So they, they've heard a cute blog post, the web's most tolerated feature 00:43:25.553 --> 00:43:28.193 looking into Zoom and how Zoom works. 00:43:28.703 --> 00:43:30.473 And it is kind, it's kind of cute. 00:43:30.473 --> 00:43:33.953 I don't know, just like it's a fun look at standards and like how. 00:43:35.008 --> 00:43:39.208 Cross browser implementation stuff works and how like, oh actually this like 00:43:39.208 --> 00:43:43.678 totally unstandardized thing just happens to work really well and everyone uses it. 00:43:44.278 --> 00:43:44.788 So, I don't know. 00:43:44.788 --> 00:43:45.178 It's cute. 00:43:45.208 --> 00:43:50.368 It's a cute post from people who are deeply involved in the standardization 00:43:50.368 --> 00:43:54.958 and implementation process, highlighting a case where like standards like just 00:43:54.958 --> 00:43:56.608 kind of didn't happen and it was fine. 00:43:56.608 --> 00:44:01.168 Anyway, yeah, there was another good post from front end Masters who I, 00:44:01.168 --> 00:44:04.168 I've just always had a soft spot in my heart for front end masters 00:44:04.168 --> 00:44:09.148 because they were, that's the first platform that I learned react from. 00:44:09.148 --> 00:44:12.328 It was like a comparative class of Angular React and Ember, and 00:44:12.328 --> 00:44:13.708 I was like, oh, react seems nice. 00:44:14.188 --> 00:44:17.398 So like I owe them a debt to, you know, my entire career. 00:44:17.398 --> 00:44:18.388 So that's, it's cool. 00:44:18.388 --> 00:44:20.758 It's nice to see 'em still around and still staying on the ball. 00:44:21.313 --> 00:44:25.963 They published a post What you Need to Know about Modern CSS 2025 edition. 00:44:26.023 --> 00:44:27.038 Mark: And it was long too. 00:44:27.338 --> 00:44:27.918 It was long. 00:44:28.093 --> 00:44:30.913 Carl: It's big and I appreciate that because I've gone to a couple 00:44:30.913 --> 00:44:35.653 of conferences and I've seen talk from various people who are more, 00:44:35.983 --> 00:44:38.283 who work on CSS a little bit more. 00:44:38.423 --> 00:44:41.893 Una Kravets, I think is who I'm most specifically thinking of, who's 00:44:41.893 --> 00:44:44.263 wonderful and great and a great speaker. 00:44:44.383 --> 00:44:48.673 But like I'll see her talk about some CSS stuff and be like, wow, all of 00:44:48.673 --> 00:44:52.723 this is stuff that I've never heard of and CSS is completely different than 00:44:52.723 --> 00:44:54.613 what I've used in a lot of my career. 00:44:54.823 --> 00:44:55.783 That's awesome. 00:44:55.783 --> 00:44:58.123 And I don't know what to do about that. 00:44:58.123 --> 00:45:03.613 So this is a great post for me in that situation and going, ah, I need to 00:45:03.613 --> 00:45:07.333 catch up on like the last six years of stuff that I haven't really paid close 00:45:07.333 --> 00:45:09.403 attention to as it evolves step by step. 00:45:09.433 --> 00:45:10.423 So, great summary. 00:45:10.928 --> 00:45:15.668 Mark: We have a few different posts on browser behavior. 00:45:16.058 --> 00:45:19.478 So there was I and all from folks who have worked on browsers 00:45:19.478 --> 00:45:20.948 for a long time, I might add. 00:45:21.278 --> 00:45:26.888 Jake Archibald did one on fetch streams are great, but don't use them for 00:45:26.888 --> 00:45:30.518 measuring upload download progress points out that you still basically 00:45:30.518 --> 00:45:32.678 need to use XHR for that instead. 00:45:33.038 --> 00:45:36.278 Although there's discussion of adding some new options and 00:45:36.278 --> 00:45:40.448 callbacks to fetch that might accurately handle that at some point. 00:45:40.688 --> 00:45:46.538 There was one from Nolan Lawson talking about why do browsers throttle JS timers? 00:45:46.928 --> 00:45:50.828 So you know, why does that time timeout zero actually be, why is it more 00:45:50.828 --> 00:45:52.778 like four milliseconds, et cetera? 00:45:53.228 --> 00:45:58.418 And basically it's because people rate bad code or either intentionally or 00:45:58.418 --> 00:46:00.578 unintentionally that can do bad things. 00:46:01.148 --> 00:46:07.488 And then Addy Osmani did a pretty long post a, mid-level overview of how 00:46:07.488 --> 00:46:13.008 modern browsers work overall, going from, you know, parsing JavaScript 00:46:13.008 --> 00:46:17.898 in HTML in various ways to using GPUs to put pixels on the page. 00:46:18.438 --> 00:46:20.298 Carl: Yeah, it's funny to me to see, I don't know, I've just been 00:46:20.298 --> 00:46:26.148 seeing Addy Osmani and Nolan Lawson and Jake Archibald for so long. 00:46:26.178 --> 00:46:30.858 It's like, man, how great for them to

stay on the top of the game for so long. 00:46:31.105 --> 00:46:31.525 It's great. 00:46:32.005 --> 00:46:33.415 One that I like here. 00:46:33.415 --> 00:46:38.425 I like seeing Vercel and Biome collaborated on stress testing, biomes 00:46:38.425 --> 00:46:40.525 new, no floating promises lint rule. 00:46:41.035 --> 00:46:46.465 I, again, have a soft spot in my heart For Biome, I was a initial backer of Rome back 00:46:46.465 --> 00:46:51.805 in the day, which was then forked after some maintainer shenanigans into Biome. 00:46:52.165 --> 00:46:55.465 They never really achieved the original vision, or have not yet at 00:46:55.465 --> 00:46:59.995 least, which was like unified, like linting compiling, you know, one 00:46:59.995 --> 00:47:01.525 tool to rule them all kind of thing. 00:47:02.389 --> 00:47:05.389 That it was called Rome because all paths, all roads lead to Rome, 00:47:05.389 --> 00:47:07.220 so it was trying to do all of it. 00:47:07.669 --> 00:47:12.769 They have achieved a lot of their goals, but not quite enough to really 00:47:12.769 --> 00:47:14.839 meaningfully claim to do all of it. 00:47:15.289 --> 00:47:18.829 Mark: It's become a pretty solid, a pretty solid formatter, but they never 00:47:18.829 --> 00:47:23.240 really managed to get into any of the multi tools sharing one a ST side. 00:47:23.809 --> 00:47:24.319 Carl: Yeah, right. 00:47:24.319 --> 00:47:24.950 Oh, that was it. 00:47:24.950 --> 00:47:28.369 It was because you know, you, you would have like Babel and ES lint and 00:47:28.369 --> 00:47:32.209 TypeScript and prettier and all of those, and all of them were independently 00:47:32.209 --> 00:47:34.430 parsing ASTs and then operating on. 00:47:35.180 --> 00:47:36.859 So like that's just a lot of wasted effort. 00:47:36.859 --> 00:47:40.549 So the, the goal was, the original goal was like one AST, all of this 00:47:40.549 --> 00:47:44.240 stuff talking to that will be an order of magnitude performance improvement. 00:47:44.330 --> 00:47:44.419 Mark: Mm-hmm. 00:47:44.779 --> 00:47:48.950 Carl: But anyway, so enough background, they have a new no floating promises 00:47:48.950 --> 00:47:54.229 rule because if you don't await or you know, respond to a promise, it can 00:47:54.229 --> 00:47:56.240 cause all sorts of super weird stuff. 00:47:56.600 --> 00:47:59.359 They say that, you know, a lot of engineers have campfire stories 00:47:59.390 --> 00:48:02.330 of floating promises taking down production, which is definitely true. 00:48:02.330 --> 00:48:07.580 I've definitely, a lot of the weirdest errors I've ever encountered track back 00:48:07.580 --> 00:48:11.689 to, oh, we didn't correctly wait for this promise to resolve, so this is it. 00:48:11.720 --> 00:48:17.990 This is a fun, deep dive technical writeup of how do you detect that promise. 00:48:18.424 --> 00:48:19.774 Has not been waited for. 00:48:19.834 --> 00:48:23.975 What does it even mean to return a promise when TypeScript has a built-in promise? 00:48:23.975 --> 00:48:25.355 Like construct? 00:48:25.535 --> 00:48:26.015 It's a good read. 00:48:26.015 --> 00:48:26.734 It's a good deep dive. 00:48:27.214 --> 00:48:29.705 Mark: I should point out that the article was written by Dmitri 00:48:29.705 --> 00:48:32.975 Metropolis, who just got done organizing Squiggle conf and is also 00:48:32.975 --> 00:48:34.774 the person who did Doom in Typescripts. 00:48:34.995 --> 00:48:36.585 Carl: Oh, it is, Love Dmitri. 00:48:36.674 --> 00:48:37.125 Love that. 00:48:37.129 --> 00:48:42.705 There is a good deep dive here into Bun Install and how it's so fast. 00:48:43.305 --> 00:48:46.575 They say on average it runs seven times faster than MPM and 17 00:48:46.575 --> 00:48:48.315 fast times faster than you yarn. 00:48:48.765 --> 00:48:52.544 It's a large post and it's got a lot of real deep benchmark stuff. 00:48:52.605 --> 00:48:52.694 Mm-hmm. 00:48:53.355 --> 00:48:56.685 Mark: I think Lydia Halley wrote that one actually very well written post. 00:48:57.390 --> 00:48:58.259 Lot of detail. 00:48:58.589 --> 00:49:00.060 Carl: Wait, was she on React? 00:49:00.160 --> 00:49:03.430 Mark: I believe she was working for Vercel and left, and I think she 00:49:03.430 --> 00:49:05.819 actually just joined Bun as a DevRel. 00:49:06.220 --> 00:49:06.580 Carl: Great. 00:49:06.580 --> 00:49:09.009 I'm just always here for like a deep technical dive. 00:49:09.190 --> 00:49:11.799 So many, so many blog posts are just a little bit more surface level, so 00:49:11.799 --> 00:49:16.690 seeing something more like a white paper, a technical writeup, I just love 00:49:16.690 --> 00:49:21.856 I, it's such a good window into the real challenges that different people 00:49:21.856 --> 00:49:23.476 around our industries are encountering 00:49:23.986 --> 00:49:28.906 Mark: for folks who are still using style components, the sanity company actually 00:49:28.936 --> 00:49:35.476 forked the existing now unmaintained library and made a couple major updates. 00:49:35.476 --> 00:49:40.366 One, to try to optimize the overall performance and another 00:49:40.366 --> 00:49:43.126 to try to provide React 19 compat. 00:49:43.636 --> 00:49:49.306 They say they are not maintaining these forks per se, but they 00:49:49.306 --> 00:49:52.546 have done the work because they themselves still relied on it. 00:49:52.876 --> 00:49:55.726 And so they've made those, they've published those so that 00:49:55.726 --> 00:49:57.136 other people can benefit from it. 00:49:57.616 --> 00:50:01.366 So if you're still work, still using style components, you may 00:50:01.366 --> 00:50:02.266 want to take a look at that. 00:50:02.806 --> 00:50:06.166 Also saw a nice little post that talked about building your own 00:50:06.166 --> 00:50:10.936 get static props alike equivalent if you're using Vite for SSR. 00:50:11.511 --> 00:50:16.041 And in the frameworks that are not actually React, but

related category. 00:50:16.191 --> 00:50:20.661 Dominic Getaway, who originally created a React Delight called Inferno and 00:50:20.661 --> 00:50:25.581 was on the React team for a while, has built his a new independent framework 00:50:25.581 --> 00:50:30.111 called Ripple, which tries to pull together some new ideas around template 00:50:30.111 --> 00:50:35.211 compilation and use of JS syntax, but in a way that's different than React. 00:50:35.721 --> 00:50:38.691 And then Michael Jackson and Ryan Florence continue to drop assorted 00:50:38.691 --> 00:50:42.711 hints online about what their Remix version three is going to look like. 00:50:42.951 --> 00:50:48.621 Michael's latest tweets are saying, what if he could just sort of use iframes or 00:50:48.621 --> 00:50:51.741 iframe like behavior for async loading? 00:50:52.251 --> 00:50:57.621 And I really just want to see the actual examples at this point, but they're 00:50:57.621 --> 00:51:00.141 dropping hints about what it'll be like. 00:51:00.141 --> 00:51:05.121 And oh, the plan is to actually show stuff off at Remix Jam, which 00:51:05.121 --> 00:51:06.981 I think is coming up next month. 00:51:07.421 --> 00:51:07.691 Carl: Yep. 00:51:07.961 --> 00:51:09.491 I am skeptical. 00:51:09.611 --> 00:51:14.351 I don't know, I, I appreciate the broad strokes of iframe, but the actual 00:51:14.351 --> 00:51:19.811 security constraints of using iframes is, that's just not, they're not good. 00:51:20.321 --> 00:51:20.981 It's not pleasant. 00:51:21.161 --> 00:51:26.051 It's not, you know, that's very like 2003 era web development and we stopped 00:51:26.051 --> 00:51:27.221 doing that because it kind of sucked. 00:51:27.281 --> 00:51:28.571 It was hard to make good experiences. 00:51:29.141 --> 00:51:31.721 If it's not literally in I frames, that's very different. 00:51:31.721 --> 00:51:33.521 So maybe it'll be better than that. 00:51:33.971 --> 00:51:37.361 There's an argument to be made that what he is talking about 00:51:37.541 --> 00:51:42.191 shares significant overlap with the islands style micro front ends. 00:51:42.701 --> 00:51:45.221 So, I'm not checked out. 00:51:45.401 --> 00:51:48.101 I'm curious, but I'm skeptical. 00:51:49.001 --> 00:51:49.481 Unfortunately. 00:51:49.481 --> 00:51:52.571 It sounds like Mo's having like significant internet challenges 00:51:52.661 --> 00:51:53.471 in his office right now. 00:51:53.471 --> 00:51:56.711 So I'm gonna, I'm gonna pull in some of the stuff that would've been, you 00:51:56.711 --> 00:51:57.761 know, that he wanted to talk about. 00:51:57.911 --> 00:52:06.026 There's been a RFC for React native, for a plan for actually removing the 00:52:06.026 --> 00:52:11.096 old architecture, the previous way of serializing communication between the 00:52:11.096 --> 00:52:12.986 JavaScript engine and the native layer. 00:52:13.316 --> 00:52:17.546 So it's not only, not only is the new architecture default, they are 00:52:17.546 --> 00:52:21.806 now proactively communi or they're proactively planning how to get rid 00:52:21.806 --> 00:52:23.546 of the old architecture entirely. 00:52:23.996 --> 00:52:25.076 Well, that's great. 00:52:25.106 --> 00:52:28.166 That feels like a big step towards 1.0, like we were talking about before. 00:52:28.676 --> 00:52:35.276 Mark: So CloudFlare announced a new tool called Cap'n Web, which is a RPC system 00:52:35.306 --> 00:52:38.366 meant for browsers and web servers. 00:52:38.486 --> 00:52:43.976 And this was created by the same person who, by Ken and Varta, who had created 00:52:43.976 --> 00:52:49.766 a couple other serialization libraries, one called Capin Proto, and Capin. 00:52:49.766 --> 00:52:54.326 Proto works with both c plus plus and JavaScript and possibly 00:52:54.326 --> 00:52:55.436 a couple other languages. 00:52:55.886 --> 00:52:59.516 And Capin proto is sort of a follow on that's specifically meant for 00:52:59.516 --> 00:53:04.616 use with web and can be sent back and forth using just plain JSON. 00:53:05.476 --> 00:53:09.226 I believe the article actually kind of pitches it sort of as an 00:53:09.226 --> 00:53:11.746 alternative to GraphQL in a way. 00:53:12.166 --> 00:53:17.866 It actually does a funky little thing where if you make what looks like an 00:53:17.866 --> 00:53:24.256 initial request for an item and then you get back a promise for that response, 00:53:24.556 --> 00:53:29.146 you can call map on the promise and. 00:53:29.801 --> 00:53:34.151 Essentially map over what will be the list of items and say, for example, 00:53:34.151 --> 00:53:38.891 gimme details on all the child items by their id, but then it'll actually 00:53:38.891 --> 00:53:41.891 get batched up into a single request. 00:53:42.251 --> 00:53:45.881 So there's some technical trickery going on there, but it sounds like 00:53:45.881 --> 00:53:51.431 it's meant to simplify both making a request back and forth and managing the 00:53:51.431 --> 00:53:56.051 overhead of what would've potentially been many independent requests as well. 00:53:56.501 --> 00:53:59.321 Thus, the comparison to like a GraphQL style thing. 00:53:59.831 --> 00:54:00.281 Carl: Interesting. 00:54:00.821 --> 00:54:01.991 And also, I'll shout out. 00:54:02.416 --> 00:54:07.516 You know, Cap'n Proto here is spiritually very similar to the challenge, it's 00:54:07.516 --> 00:54:11.326 solving a problem that's spiritually very similar to the new architecture and 00:54:11.326 --> 00:54:16.006 React Native, like basically, you know, this RPC is going instead of going across 00:54:16.006 --> 00:54:20.926 like a native JavaScript layer, like a new React native, this is how do you do 00:54:20.926 --> 00:54:24.796 a similar type of communication between systems across the network boundary? 00:54:25.246 --> 00:54:28.916 And the challenge is like the reason you would use something like Cap'n 00:54:28.936 --> 00:54:33.496 Proto or Protocol

Buffers, which you know, there's kind of competitors there 00:54:33.556 --> 00:54:39.916 is because the serialization costs and the volume of communication if 00:54:39.916 --> 00:54:43.576 you're using JSON, is just much higher, like converting it into a string. 00:54:43.756 --> 00:54:46.186 It's basically a string versus a binary data format. 00:54:46.516 --> 00:54:51.586 Like the, one of the problems with JS is that you're encoding not just 00:54:51.586 --> 00:54:53.056 the data, but also the structure. 00:54:53.116 --> 00:54:56.296 You're saying, here's the object, here's the keys, here's what it looks like. 00:54:56.836 --> 00:54:57.136 And that's. 00:54:57.866 --> 00:54:58.706 That's information. 00:54:58.706 --> 00:55:00.686 You know, if you're sending that information across the 00:55:00.686 --> 00:55:02.666 wire, that's extra effort. 00:55:02.696 --> 00:55:07.616 If you already have two, two agents on opposite ends of a network and they 00:55:07.616 --> 00:55:13.196 say, we agree that our communication is in this format, then you don't need 00:55:13.196 --> 00:55:15.716 to send the format across the wire. 00:55:16.226 --> 00:55:21.386 So that's the fundamental like reason why you might use one of these tools 00:55:21.386 --> 00:55:25.286 instead of just sending JSON over HTTP and yeah, it's interesting. 00:55:25.286 --> 00:55:26.246 This is, it's pretty cool. 00:55:26.756 --> 00:55:27.056 Cool. 00:55:27.086 --> 00:55:33.056 The Expo had an interesting post talking about using Swift UI in React 00:55:33.056 --> 00:55:35.336 Native, so that, that's pretty cool. 00:55:35.336 --> 00:55:38.486 Like being able to directly, if you're in, only, if you're only targeting 00:55:38.486 --> 00:55:40.346 a native environment, being able to. 00:55:40.826 --> 00:55:44.306 Exclusively use native primitives is like a huge win. 00:55:44.306 --> 00:55:48.266 Like if you don't, you know, it's always good to remove compatibility layers 00:55:48.296 --> 00:55:50.006 if you don't need the compatibility. 00:55:50.456 --> 00:55:51.086 So that's really cool. 00:55:51.086 --> 00:55:55.076 It's it, this looks pretty interesting if you're doing stuff on Mac Os or 00:55:55.076 --> 00:55:57.026 like Apple TV or things like that. 00:55:57.566 --> 00:56:00.536 Mark: So the TanStack folks recently announced a new package called 00:56:00.706 --> 00:56:05.396 TanStack DB, which is supposed to be a smart syncing layer on 00:56:05.396 --> 00:56:10.586 top of TanStack Query that can do things like in-memory filtering and 00:56:10.586 --> 00:56:13.046 querying of data very efficiently. 00:56:13.496 --> 00:56:18.056 And so there was a neat post that was an interactive guide to TanStack db 00:56:18.056 --> 00:56:20.936 and discussing some of the options and some of the things you can do with it. 00:56:21.446 --> 00:56:26.186 Carl: TypeScript version six may switch to strict options by default. 00:56:26.756 --> 00:56:27.536 This is, 00:56:27.536

--> 00:56:28.496 Mark: hallelujah. 00:56:28.766 --> 00:56:29.486 Carl: Yeah, right. 00:56:29.486 --> 00:56:30.386 What a long time coming. 00:56:30.386 --> 00:56:33.086 Like I have treated this as a deep, you know, this has been step one of 00:56:33.086 --> 00:56:36.716 setting up a new TypeScript project for me since I've started using TypeScript. 00:56:36.716 --> 00:56:38.426 'cause it's always been the best practice. 00:56:38.486 --> 00:56:42.446 So I love that they are discussing, switching this over. 00:56:42.596 --> 00:56:42.806 Yeah. 00:56:43.166 --> 00:56:45.266 It starts almost a decade ago. 00:56:45.266 --> 00:56:49.646 We began to add certain options beyond, no implicit any in strict no checks. 00:56:49.976 --> 00:56:52.466 So, yeah, like almost a decade ago. 00:56:52.826 --> 00:56:53.996 So that's the, that's cool. 00:56:54.056 --> 00:56:58.676 TypeScript 6.0 will assume that dash dash strict is on unless explicitly disabled, 00:56:59.126 --> 00:57:02.756 which means specific settings like strict no checks and no implicit any will be 00:57:02.756 --> 00:57:05.336 enabled unless it's turned off explicitly. 00:57:05.846 --> 00:57:05.906 Woo. 00:57:05.936 --> 00:57:06.446 Cool. 00:57:06.446 --> 00:57:11.996 No implicit any is if you don't turn that off, like you're not really using Patrick, 00:57:11.996 --> 00:57:13.676 like it's just sparkling JavaScript. 00:57:14.261 --> 00:57:15.251 So that cool. 00:57:15.251 --> 00:57:15.701 Love that. 00:57:15.791 --> 00:57:16.601 Love to see this. 00:57:16.991 --> 00:57:20.771 Mark: There's a lot of debates over the nuances of what that concept of turning 00:57:20.771 --> 00:57:22.961 on strict by default actually means. 00:57:22.991 --> 00:57:26.441 But I would assume that something along those lines would land 00:57:26.441 --> 00:57:27.791 and yeah, it's way overdue. 00:57:28.301 --> 00:57:32.261 Alright, last couple ones and then we're done with the not so lightning. 00:57:32.291 --> 00:57:36.011 Lightning round Shopify put up a post talking about their migration to the 00:57:36.011 --> 00:57:39.821 React native new architecture and went through both some pros and cons and 00:57:39.821 --> 00:57:42.161 pitfalls of what that process involved. 00:57:42.311 --> 00:57:47.321 And then the last one is from James, who has the really funky username that 00:57:47.321 --> 00:57:51.041 I'm not even going to try to pronounce, but he's been working as part of the 00:57:51.131 --> 00:57:54.911 E 18 E ecosystem speed up process. 00:57:54.911 --> 00:57:58.931 In fact, he's the person that I did a stream on a couple days ago 00:57:59.201 --> 00:58:02.831 where we talked about my work to make the Immer library faster. 00:58:03.311 --> 00:58:08.411 And his post looks at like, gives an example of, let's say you have a math 00:58:08.411 --> 00:58:10.421 clamp function that takes some arguments. 00:58:10.901 --> 00:58:14.561 But you don't want it to crash if someone does something

stupid like passing in, 00:58:14.591 --> 00:58:19.151 you know, a string instead of a number and next thing you know, like two thirds 00:58:19.151 --> 00:58:24.341 of your function is just validating the inputs before it actually does anything. 00:58:24.851 --> 00:58:26.741 And he argues that, you know what? 00:58:26.771 --> 00:58:31.841 This actually ends up being kind of a waste of space and execution time. 00:58:32.231 --> 00:58:36.131 And that to a certain extent, if someone passes in bad input, that's 00:58:36.131 --> 00:58:40.121 their problem and not your problem, which I can sort of get behind. 00:58:40.661 --> 00:58:41.981 Carl: Yeah, interesting. 00:58:41.981 --> 00:58:42.851 That makes a lot of sense. 00:58:43.181 --> 00:58:46.481 It's kind of the right, it's a challenge between sharing code and doing it inline 00:58:47.201 --> 00:58:50.291 how when you start trying to do it inline, you end up re-implementing a lot. 00:58:51.311 --> 00:58:51.701 Cool. 00:58:51.731 --> 00:58:52.961 Let's talk about some conferences. 00:58:53.381 --> 00:58:57.011 We have in like three days, two days. 00:58:57.491 --> 00:59:00.881 React Alicante in Spain, October 2nd through fourth. 00:59:01.691 --> 00:59:02.711 Mark: I will be speaking there. 00:59:02.711 --> 00:59:04.031 I'm flying out on Wednesday. 00:59:04.541 --> 00:59:04.961 Carl: Woo. 00:59:05.021 --> 00:59:05.681 And then you're fly. 00:59:05.981 --> 00:59:06.701 And then you're flying 00:59:07.391 --> 00:59:08.921 Mark: all the back and then flying all the way back across, across 00:59:08.921 --> 00:59:11.411 the world for to attend React Conf. 00:59:11.741 --> 00:59:12.131 Carl: Yep. 00:59:12.521 --> 00:59:13.421 I'll be there too. 00:59:13.511 --> 00:59:17.381 So yeah, react Conf in Henderson, Nevada, right near Vegas. 00:59:17.921 --> 00:59:21.731 I'm actually gonna be driving from San Jose, so like if you're 00:59:21.731 --> 00:59:26.171 in the Bay Area a couple days before the React conf, lemme know. 00:59:26.231 --> 00:59:26.561 I don't know. 00:59:27.281 --> 00:59:29.471 I'm gonna go hiking, so, we'll, it's gonna be an adventure. 00:59:29.681 --> 00:59:33.701 Then a couple days after React Conf, Remix is doing their own 00:59:33.701 --> 00:59:37.961 conference in Toronto, the Remix Jam. 00:59:37.961 --> 00:59:38.681 So yeah, maybe. 00:59:38.681 --> 00:59:39.581 We'll, we will see. 00:59:40.121 --> 00:59:41.891 It'll be interesting to see what they come out with. 00:59:42.251 --> 00:59:43.451 Yeah, I'm curious. 00:59:43.611 --> 00:59:43.881 Yeah. 00:59:43.941 --> 00:59:47.856 Anyway, coincident with that, ViteConf is happening October 00:59:47.856 --> 00:59:49.371 9th and 10th in Amsterdam. 00:59:49.896 --> 00:59:50.436 That'll be cool. 00:59:50.676 --> 00:59:51.936 Love to see what they come out with. 00:59:52.476 --> 00:59:57.036 JSConf is doing a couple of events all over the world actually, so they're 00:59:57.036 --> 01:00:03.486 doing JSConf North America October 14th through 16th in Chesapeake Bay, Maryland, 01:00:03.966 --> 01:00:10.266 and they're also doing re JSConf Chile, October 24th and 25th in Santiago, Chile. 01:00:10.806 --> 01:00:18.126 We've also got, after that React Native London, October 30th and 31st, 01:00:18.696 --> 01:00:21.666 Mark: and Mo runs that, so you should totally be there and support him 01:00:22.056 --> 01:00:25.956 Carl: after that, there's React India October 31st and November 1st, 01:00:26.316 --> 01:00:29.676 and then the Wey Wey Web, I think I'm pronouncing that right. 01:00:29.676 --> 01:00:33.276 It says it's a yay, yay conference, international conference for ux. 01:00:33.876 --> 01:00:38.406 But yeah, that's happening in Malaga, Spain, November 17th and 18th. 01:00:39.096 --> 01:00:43.266 And then we've got React Summit happening in New York, November 18th through 21st. 01:00:43.776 --> 01:00:44.556 So that's cool. 01:00:44.676 --> 01:00:44.976 We'll see. 01:00:44.976 --> 01:00:45.876 Maybe I can make it to that. 01:00:46.236 --> 01:00:48.366 It's in my hometown, so Yeah, that'd be great. 01:00:48.876 --> 01:00:49.686 Mark: And then React. 01:00:49.686 --> 01:00:56.796 React Advanced is November 28th, all and although it's uh, inconveniently the day 01:00:56.796 --> 01:01:00.936 after us Thanksgiving this year, they had done it in late October, previous 01:01:00.936 --> 01:01:04.596 years, and I think since they're not doing React Berlin, they bumped the 01:01:04.596 --> 01:01:08.346 schedule for React Advance to be sort of in the middle where those would've been. 01:01:08.766 --> 01:01:10.176 Carl: That's everything we got for you this month. 01:01:10.266 --> 01:01:11.796 Thank you so much for joining us. 01:01:12.336 --> 01:01:15.486 We'll be back on the last Wednesday of the month probably, although we had 01:01:15.486 --> 01:01:17.256 to reschedule this month again, sorry. 01:01:17.916 --> 01:01:20.826 Or we will be back in your podcast feed just as soon as we can. 01:01:21.366 --> 01:01:24.096 We gather sources from, actually this month we pretty much only 01:01:24.096 --> 01:01:25.386 gathered sources from Reactive Fly. 01:01:25.746 --> 01:01:28.866 It was a good month for, you know, us staying up to date. 01:01:29.496 --> 01:01:35.316 Yeah, generally we do subscribe to this week in React, which is a great source. 01:01:35.751 --> 01:01:40.041 Follow lots of people on Blue Sky and Twitter, the React JS subreddit and just, 01:01:40.071 --> 01:01:41.301 you know, generally all over the internet. 01:01:41.301 --> 01:01:42.561 We try and stay in touch. 01:01:42.651 --> 01:01:46.851 If you see anything that you think that we should be aware of, definitely post. 01:01:46.851 --> 01:01:49.401 Actually, you should just post it to the Tech News and Reads channel here. 01:01:49.431 --> 01:01:53.301 I would love it if we could have some more chatter going on there and it 01:01:53.301 --> 01:01:56.811 really does help us stay on top of things and helps me understand it. 01:01:56.811 --> 01:01:59.301 If, you know, if you post a link and then you and somebody else 01:01:59.301 --> 01:02:02.541 have a conversation, I will read that and it will inform my opinion. 01:02:02.601 --> 01:02:04.281 So yeah, it's a great way to do it. 01:02:04.791 --> 01:02:07.461 If this is a show that you get value from and wanna support, best way to 01:02:07.461 --> 01:02:12.111 do so is by reviewing us on whatever platform you listen to or tell your 01:02:12.111 --> 01:02:13.041 friends and coworkers about it. 01:02:13.041 --> 01:02:13.821 So, you know, send 'em a link. 01:02:14.331 --> 01:02:14.691 Cheers. 01:02:14.871 --> 01:02:15.651 Thanks so much for listening.