TMiR 2025-09: React 19.2 on the horizon; npm is still getting compromised

Transcript from Sunday September 28th, 2025

This Month In React - September 2025 (SM)

Carl: Alright. Hello everyone. Thank you for joining us for the September edition of this Month In React. As we, uh, get together and recap what's going on with React, react Native and the web, we're coming to you live from Reactiflux, the place for professional developers using React. I am Carl. I'm a staff product developer and freelance community leader here in Reactiflux, where I do community programs like these events and build tools to help keep the community operating. [00:00]

Mark: Hi, I'm Mark. My day job is working at Replay.io and digging into the guts of React and its internals. And in my copious amounts of spare time, I'm currently rewriting the guts of Immer for faster performance. [00:23]

Carl: Yeah, you did a live stream on that. That was cool. [00:34]

Mark: Yeah, that was a lot of fun. [00:36]

Mo: And my name is Mo. [00:37]

I am the head of Mobile at Thedo. And yeah, I spent a lot of time in the React and React native communities, speak at conferences here and there, and organize the React Native London Meetup and conference, which is coming up in November. [00:38]

Carl: Yeah, more on that later. [00:51]

New releases

Carl: Let's jump into some new releases. [00:52]

TanStack Start 1.0 RC!

Carl: We're gonna talk more about this in depth in the main content section, but Tan Stack start has released a 1.0 rc, so that should be coming together. I've tried playing with this a little bit and didn't make it too far. It just ended up being a larger task than I really imagined, but I'm excited about it. [00:54]

react-window 2.0 rewrite

Mark: React Window. Just put out a version 2.0. Brian Vaughn did a pretty major rewrite of the library to try to simplify some of the props and add some nice built-in features like automizing of the list items and auto resizing. So you no longer need a resize plugin to handle that. [01:13]

Carl: Oh, that's nice. Okay. Yeah, and react window is efficiently rendering large lists. [01:32]

Mark: It's virtualizing lists. Yeah, so you got a list of, you know, a million items. You can only show a hundred on screen at once, that sort of thing. [01:36]

Apollo Client 4.0

Mark: Also, on that note, Apollo client for GraphQL just put out version 4.0. I know this was a, a pretty major effort to try to improve the packaging, consolidate. Remove a bunch of deprecated features, so that should be a significant improvement if you're using Apollo. [01:44]

Redux Toolkit 2.9.0

Mark: And on my side, I actually just shipped a Redux toolkit 2.9 earlier this month. The biggest thing there is I made a bunch of perf optimizations to RTK query, especially for cases where you've got a lot of components that are reading from the same cache entry. And we also added a few new options and bug fixes, but the perf improvement and some in-flight requests cleanup was, were some of the biggest pieces there. [01:59]

Carl: Okay. Yeah. Not too many new releases for open source libraries this month, I guess. [02:25]

Mark: Well there, there probably were a few more. We just didn't collect them. [02:30]

Carl: Yeah, I wish there were a little bit more consistent standards across the ecosystem for how to publish a list of new releases. Like the GitHub release is, it is pretty good, but it's still only like 60% hit rate, I guess. Something like that. [02:32]

It feels like. [02:46]

Main Content

Carl: Cool though. Let's go into our main content. Can you tell us a bit about React updates? [02:47]

React 19.2 coming soon?

Mark: I don't actually have any real details on this, but Rick Hanlon from the React team tweeted out like yesterday, a screenshot of himself apparently working on release notes for React 19.2, so I would assume it's fair to say that it's probably coming out in the near future associated with that and potentially coming out in 19.2. Although the timing may be a little too soon, we have two React features that have graduated from the experimental branch to the Canary branches. [02:52]

in canary, with docs

Mark: The first one is the new activity component. This has been around in some form in in the experimental branches for. Probably multiple years at this point. It was originally known as the offscreen component, and then they officially renamed it to the activity component maybe about six or eight months ago. [03:24]

And this is gonna be a pretty big deal. So one of the issues with React has always been that built-in state is managed at the component level. And if you unmount a component, then it, you know, both cleans up the effects and they go away. But the state that was in that component goes away as well. And so that's one of the reasons why there's been, you know, so much use of external state libraries like, you know, Redux and Juice end and Jot and MobX over the years is because in order for state to persist, you either needed. [03:45]

To have the state live outside UAC component tree, or you needed to hoist it up to the top and pass it down via context or props and if you unmount a section of the tree that DA and that data could go away. So the activity component is going to allow you to essentially disable and hide a section of the component tree, but react will keep around the state for those components. [04:22]

And in fact this actually kind of goes along with some of the strict mode stuff that people have, you know, complained about for years. The activity component will also unmount the effects for the components that got hidden. People have complained for years, you know, strict mode, double running effects, you know, shows bugs and, and all the other things like that. [04:52]

But part of the point of that has been to work towards, eventually this feature will come out where you can toggle the activity component on and off. And React will run the UNM mounts because the components aren't fully mounted, therefore, they shouldn't have active effects going. But it will keep the state for those components alive. [05:14]

And so you can imagine this could be useful for a couple of different things. One is like a tabs component. Right now, if you have a tabs component, you either stop rendering the other tabs completely as you switch back and forth, or you use something like CSS display, none, which means the tabs are active and in the page, even though they're not even being displayed. [05:37]

And so with the activity component, you can say I want to pre-render the content for the other tabs, but it's not actually attached to the page until we swap back and forth. But they could still persist the state. So if someone goes back and forth between the different tabs and makes some edits, then. [05:59]

You know, that still stays alive. There's a comment in the chat that the naming choice for the component seems very strange to me. I agree. I didn't like it either. There was some rationale in the PR that actually renamed it to activity. I don't remember what it, what it was specifically off the top of my head, but they, I think it was that like, it's more about is the component active rather than is it quote unquote off screen. [06:19]

Yeah. But I, I don't entirely buy that myself. [06:46]

Carl: Yeah, right. Because this is like hitting that midpoint between that decision point of do you render null or do you render the dom with styling to suppress its visibility. And so I guess this is like smack in the middle, like the internal representation of all of that. [06:51]

Dom remains. But you don't use styling to hide it, which is great for cross-platform stuff. 'cause like there wasn't a cross-platform way to hide something as far as I know before. [07:07]

last React Labs post mention

Mark: So if I, if I look back at the last React Labs post from April where they talk about, you know, the plans for the activity component, there's a section there that says, in the future we may add more modes for activity. [07:18]

One of them could be content visible, but keep it unmounted and pause dom updates. Another is the ability to destroy state for hidden activities if too much memory is being used. So I think part of the mindset is it's not just like a bullion toggle, it's we're shipping with two mode options that are like a bullion toggle for now. [07:31]

But we envision some possible additional modes for this down the road. [07:57]

Mo: And, and you know, this is like particularly interesting to me because this has like been a long standing problem in the React native space when you're dealing with native apps. And I, I doubt this will work out of the box with React Native, but I think it's gonna be one of those things which will eventually get there. [08:02]

And hopefully the new architecture makes this easy for the, the core team to adopt and like make sure that those APIs are working correctly. But it's a classic issue, especially when in Native world you're dealing with this concept of like stacks of pages on top of each other. You really don't want the, the stacks that aren't visible or the pages that aren't visible in your stack showing or getting all of the DOM updates, or in this case this, the updates to the actual screens whilst they're inactive because that's a massive performance bottleneck on native devices. [08:17]

And so this type of thing, people have massed over it in the most dirty ways possible and hacky ways possible in, in the React native world. It's been like a longstanding problem because if you, you know, unmount them and then remount them and reestablish the state, there's sometimes like a flashing white screen before the actual components reload. [08:46]

Then you need to delay the transition because all of these things are like transition with page transitions and native. So it's basically to say there's a lot of complexity and if there's a native React way to deal with this, that ties into navigation on the native device as well, then I think it's gonna be a game changer and it'll simplify and fix a lot of performance issues that people often have with their React native apps. [09:05]

Mark: Yeah, I, I know we've, we've had a couple of open issues on the react-redux repo with people complaining that. Components that are off, quote unquote offscreen in the React native stack are still subscribed to Redux updates and taking up perfects from running all the subscription logic and asking for us to add random options to make that toggle or something. [09:26]

And so if you know, the activity component ought to be the built-in solution for that. And so that would actually means we don't have to do anything, which is great. Yeah, exactly. [09:48]

Mo: And you know, like some state management libraries have adopted some work around components that you can use for that, but it comes with trade-offs, right? [09:57]

And ideally, your state management library really should not worry about this. This feels like a core react primitive problem rather than a state management library problem. To me, [10:06]

Carl: back to what you said about like the layering of UI and performance problems and like listening to events and things. Fun fact, I've chatted with some people who did React native or like React UI for automotive companies and that was a problem they dealt with like sometimes for certain cars. [10:15]

The reason the UI sucks sometimes is because of this issue and because it's rendering multiple UIs on top of each other and doing all sorts of weird, crazy stuff. There's two [10:35]

Mo: devices that are particularly bad for that. One is Smart TVs and the other one is cars. And the reason for that is both of them are awful processors and like they really cheap out on the hardware because they're cutting costs everywhere in the actual like manufacturing bit. [10:45]

And so something that might run in your web browser with your laptop that like has like several hundred megabytes of RAM per tab. Will, you know, be restricted to 50 megabytes of ram or it'll get killed by the operating system that lives on the automotive car infotainment system. And this is a big problem for any, like one of those types of devices. [11:01]

And I think a lot of those, you'll be surprised, run on React and like web-based platforms or sometimes even rec native, and it's a big, big issue. So I think something like this. You know, you can fix those issues, but it's hacky and not everyone will do it. So then you'll get really crappy infotainment systems, like you said, Carl. [11:23]

So, [11:40]

Carl: okay. That's probably long enough talking about activity though. [11:41]

useEffectEvent in canary and has docs

Mark: So one other, one other feature that's migrated from experimental to Canary, I just saw this one a few minutes ago, is the useEffectEvent hook. This is something that the React team has also talked about for a while, and I actually didn't even know that any progress was being made on this until I just saw the PR announcement. [11:43]

I'm gonna describe this very badly. Someone should correct me on this, but it's almost like a used memo for callbacks where you'll get the latest reference to a. Callback inside when you execute it, but you get a consistent function reference back when you use it. And so this avoids the need to do a workaround where you're like, main, where the, the callback is reading something off of a ref to get the latest value. [12:04]

I know that this is something that had been proposed a while back and then the initial proposal got killed and they said, we'll, we'll come back and we'll rethink this later. And apparently later is finally now. [12:34]

Carl: Later is now. That's great. Yeah. Interesting. I'm, I'm not super up to date on this, so I'm just reading the docs right now to understand it better. [12:48]

Interesting. The, I definitely know that I have used refs. You know, red values off refs because of weird issues. So I'm not quite groking how this solves this immediately, but that's interesting. [12:57]

Mark: So, and okay, so a partial example, and again, this is me going off the top of my head and not even trying to read the post at the moment. [13:09]

So, if you have like a used callback that needs to access a value, you either let the callback get recreated every time, which in case there's no point in the use callback at all, or you have the item in the dependency array, which means it's gonna, the callback is gonna get recreated still when the value changes or you don't rate it all, and oops, now you have a steel value, which is bad. [13:17]

Carl: Right. [13:42]

Mark: So what happens when you want a consistent callback reference that never changes, but it still needs to see the latest value in order to do something useful when it runs. So one workaround for this is you put a use ref a couple lines up in the component that runs first. You assign to it even in like another use effect before the one that you care about. [13:42]

That means it gets updated. Now you've produced this kind of weird sequence of events where I know that the ref has already been updated before the callback ends up getting run. And so part of the point of this hook is to eliminate the need to do that little dance yourself. [14:08]

Carl: Yeah. Okay. That makes sense. [14:24]

I'm reading this list of caveats and it seems tricky. The only call inside effects define it just before the effect that uses them. Do not pass them to other components or hooks. Do not use useEffectEvent to avoid specifying dependencies. This can hide bugs. Sure. Use it only to extract logic that does not depend on changing value. [14:26]

That's quite a set of constraints. [14:48]

Mark: When the new docs came out, and Dan and a couple others wrote the tutorial. There were a couple pages in there that actually referenced this hook as the solution for some of the problems that were being described. Even though the hook didn't exist yet, some of the docs pages also try to make the terminology very unique, where they talk about lowercase e effects as in like, you know, just the generic concept of a side effect versus a capital E effect, which is like a somehow react specific concept that I don't think the docs ever fully defined. [14:51]

And so in, in a way like the use effect event hook, is the React team trained to somehow solidify this. Notional react effect term in a way. [15:30]

Carl: Interesting. Interesting. [15:46]

Compiler inferring function names

Mark: Alright, two other little data points and, and updates Worth noting. The React team merged a work in progress PR to the compiler to try to do and to try to automatically infer function names for things like callbacks that you pass to use effect so that you know when they show, like show up like in a stack trace, they are nicer and easier to read. [15:47]

Docs for eslint-plugin-react-hooks, including rules and compiler issues

Mark: And then the docs now have a page for the Eslint plugin of react hooks, including a bunch of information on all the different rules that it cover and that includes issues that'll get flagged by the compiler as well. [16:08]

Carl: Also, yeah, I wanna say on the compiler inferring function names like that is like one of the most quietly mind blowing things I have seen in a long time. [16:19]

I actually commented on the PR to ask like, what if this became a TC 39 proposal? Because this would have saved me days of effort over the life of my career. If there had been a little bit more data about what the heck is throwing an error instead of just like cannot read property of undefined. Oh thi this is quietly one of the mo going to be one of the most impactful changes in a long time I think. [16:29]

Mark: I have actually, even just recently in some of the Immer work that I've been doing, gone in and replaced anonymous arrow functions with a named function just to try to get a better name and a stack trace. [16:55]

Carl: Totally. Yeah, a hundred percent. And the annoyance of assigning an arrow function to a variable versus using a named function and how those are not the same thing. [17:06]

React Native 1.0 on the horizon

Mo: Cool. Let's move on to some React native news, which has gotten people a, a fair bit excited, which is one of the talks that was at React Universe comps that happened at the beginning of this month called React Native 1.0 is on the horizon. This is pretty exciting stuff because it's anecdotally, and I'm sure many people have had the same experience as me. [17:15]

One of the biggest things that people oftentimes use, which is a really, really, you know, straw man argument, but nonetheless is there, is that, oh, react native's not stable because it's not 1.0. I kid you not, when I say three weeks ago we were talking about starting a new project here at Theo and someone brought this up as a reason not to use React Native as one of like the prospective clients that we had because another company who was trying to push them to use Flutter had told them, oh, it's not stable because it's not 1.0 da da da da da. [17:37]

And you know, there's a little bit of fear mongering around this. The reality of it is that React Native has been around for way too long and it's been used in many, many serious production apps for, you know, several, several years now. And so I think this is something that a lot of people have discussed with the React Native Core team over the years. [18:06]

And you know, there's always been a bit of a reluctance on going to 1.0 for various reasons. Um, and so this talk is really interesting 'cause they talk a little bit about the history of that and what the reasons are for that. But really what's happened over the last year is that the release process for React Native has been significantly streamlined. [18:23]

So there are now six releases. Being targeted for every single year. So every other month there being a release from two releases, which was what we had in 2024 and you know, a lot more sporadic releases in the previous years. So there was no really never a schedule to it before where, whereas now there is one of the things that's been happening over the years, but really accelerated over the last, I'd say year, is that a lot of the APIs are being really stabilized, reduced, and the surfaces are being completely trimmed down. [18:38]

And so the whole idea with this is less API surfaces externally means that there's less likelihood for breaking changes in the long term, which helps them feel confident to say, Hey, this is a 1.0 or reaching out sort of monumental point where they can actively say, Hey, this is a 1.0 release. And the other thing is that the React native. [19:06]

Pipelines for building React native Core was quite a manual process in the past, and so what they've done in sort of recent years is worked on introducing a lot more end-to-end testing, some workflows that would test our C bugs and you know, breaking changes much quicker. And so that's really been a lot of the efforts behind the scenes, which you won't see in features and functionalities, but it's really been to the workflow for building React native. [19:25]

And so a lot of this is really moving us towards that direction where there can be at 1.0. And so the conversation isn't. Potentially, hey, there's gonna be a 1.0 in the next few months. Maybe not even in the next year, but it is somewhere there where they're feeling like, okay, we can go ahead to, to basically releasing a 1.0 for React native at some point in the near future. [19:48]

So the React team's gonna be, the React native team is gonna be working on this quite extensively and trying to reach a point where they're happy and so they're gonna be working with a bunch of people to start to potentially put a date on it, which is very exciting. [20:09]

Carl: That is really exciting. That's a long time towards 1.0. [20:20]

But like it would've felt premature I think for them to get, to call it a 1.0 before, or at least they would've had to do a lot of breaking. [20:22]

Mark: Even just waiting for the new architecture to be the default, I think was a big thing. Mm-hmm. Yeah, definitely. [20:30]

Carl: Yeah. And that really seems like it was a meaningful, a meaningful reason to delay, like it was such a large disruption to so many different parts of the ecosystem, but also so essential. [20:36]

Yeah, it feels more truly native under the new architecture, rather than having to like serialize between two independent systems. It kind of reminds me of like when Docker launched because it was a Linux feature, you know, a Linux kernel feature. I remember for years they had like a, if you wanted to use it on Mac, you had to technically run a vm, which introduced all sorts of weirdness. [20:47]

And so that feels, I dunno, this feels technically similar to me in how they like figured out how to not have two independent systems communicating with each other in that kind of way. And now that they've cleared that hurdle, they can get towards a greater level of stability. Cool. Awesome. [21:09]

Mark: One other thing that actually kinda reminds me of, so we had squiggle conf a week and a half ago and one of the talks was from Shelley Vohr, who's part of the Electron core team and she did a talk about automating systems and you know, things like security and repeatability and what happens if the system goes down. [21:25]

And it sounds like a lot of the effort that's been involved on the RN side really is about CI pipelines and automation and turning a manual release process into an automated release process. And you know, having that consistency is a pretty big deal here. [21:44]

“React Won by Default – And It's Killing Frontend Innovation”

Carl: Cool. Drama post? [22:02]

Mark: Drama post. [22:04]

Carl: Yeah, so there was a recent post called React Won by default and it's killing front end innovation. [22:05]

Mark: To some extent. There's nothing new in this post. People have been making complaints about this for years. [22:13]

Inevitable HN argument

Mark: It's a pretty well written post, and it did make all the rounds and spawned massive 800 comment, hacker news thread and responses on Twitter and a bunch of other places. The first argument is that React itself has kind of stagnated that it was a big deal in 2013 when the virtual do solved problems with Angular, but that React really hasn't innovated since then claim, and that things like the React compiler are a bit more of a bandaid. [22:18]

Whereas other frameworks like solid and spelt and quick are doing new and innovative things around signals and ruins and resum ability and other approaches to updating the dom. But the rest of the argument is that. The typical discussion these days for a project is, okay, which framework should we use? [22:48]

Well, let's use React because it has the biggest ecosystem, because there's the most developers available because AI are familiar with it, because there's lots of libraries out there, et cetera. And the phrase that always comes to mind and for me is the old one about no one ever got fired for choosing IBM that back in the day, like IBM was the safe choice for, you know what, whatever tools it is sort of that same principle today. [23:09]

Like most people are not generally choosing React. Because they're specifically excited about suspense or transitions or other things like that. It's the industry standard, so we'll stick with that. And so the article argues that because of that, because the mindset is used, react by default, that it's sort of choking out other frameworks that have had more innovation and newer interesting approaches. [23:39]

And so it ends up offering some suggestions for things to evaluate about scaling and performance and team skills and whatnot. And then tries to counter argue the typical like size of the ecosystem type points. It's a well-written article, like it's not flame bait. The title is is well out there, but it makes a pretty good actual point and it spawned a lot of discussion, like I said, hacker News and a bunch of other places. [24:08]

But I think the really interesting counterpoint to all that. Is Rick Hanlon from the React team put up a very long thread on Blue Sky, which really should be its own blog post at this point where he says that all the frameworks know how to update the do efficiently React has innovated in the past, but it's also, it was so good in the past. [24:34]

People are actually kind of ignoring the innovations they've done since 2017 and 2018, and that reacts focus for the last seven years has been not about how can we make Dom updates faster per se, but about scheduling. Things like concurrent mode, transitions, suspense, even the new activity component builds off of the foundations that they've built for the last several years. [24:59]

Yeah. And so his argument is that number one, when people say react is an innovating, they're ignoring all the new features built around concurrency. And number two, that most people are still thinking about using React in a very 20 16, 20 17 ish sort of way. Most people aren't even thinking about using the new capabilities that React has unlocked. [25:23]

I think he's actually got a pretty good point. [25:50]

Carl: That's fair. I would generally agree with that and like I am very much in that boat, I'll be honest, like I haven't written extensive from scratch, like build an app and react since about that time. The last time I really did that from scratch to like a full production level where I was like exclusively focused on the front end was about that time, like ended around 2021. [25:52]

So I've been following a lot of this, but I haven't used it at the same level of depth that I used to. I have seen somebody who, you know, one of my internet acquaintances who I have a lot of respect for, as you know, both technically and like entrepreneurial and whatever. He's been extolling the virtues of server components for the last couple of months, I think, and it's been on my, you know, it's been somewhere on my to-do list to talk more with him. [26:15]

Mark: Daniel Switz. [26:40]

Carl: Yep, yep. Daniel Switz. Just like I've heard him say some things. It's like, okay, I feel like you get it and I feel like you get it in a way that you could communicate. It's crossed my mind actually to have him and Ricky and or him and Dan or I don't know, a group of people on a stage like this and just like talk about it and be like, what the fuck? What are we doing? How do you do this? So yeah, I don't know. It's like, it's definitely there is innovation happening. I think a lot of the innovation, like there's innovation happening and there's also just like roadblock clearing. It's like, you know, there's the innovative, you build the road, but then you have to deal with the consequences. [26:41]

Like, great, you have this road. Like what is it like to actually use it? And then a lot of the time you realize there are speed bumps and whatever that you didn't realize you were building in the first place. And the fix there is not innovate. You don't just like, well that sucked. Let's build a new road. [27:16]

No, you fix it. Figure out different ways to approach the same problem that have a different set of trade-offs. And so I think that's some of what's being complained about here is that like people are like, we need a new thing. We need to rewrite from scratch. And No, we don't. I don't think we do. So, yeah, I don't know. [27:33]

I guess that's what I, what I have to say there. [27:52]

Ricky on Ryan Carniato’s stream talking about scheduling and demoing using modern React features

Mark: So, sort of on on that note, Ryan Carniato from the solid team routinely does streams where he talks about what he's working on or you, where the ecosystem is going. He and Ricky have had a number of like, actually. Intentional and productive discussions back and forth on Blue Sky and Twitter where Ryan has said, we've got our own version of suspense, we've got our own version of transitions. [27:54]

We're trying to do things this way. And Ricky has put up a demo and said, how does this, here's the React way to do this. How's this compare to the way you guys are doing it? And so Ricky was actually just on Ryan Carniatos stream on Friday and I looked, and it's a six hour long video. No, I most definitely did not watch the video. [28:17]

I cheated and used a summarizing tool to try to gimme a sense of what they were actually talking about. But it looked like they talked about where React has gone and what has changed with all the different concurrency related features. And then I think they tried to take a sort of a classic react. I think it was like a React 17 to do application, and then they updated it live on stream to use all the modern latest React features. [28:38]

So if you want to watch them talking about this for six hours, the video's there. But it's a good example of people who know how this, how these technologies are implemented, discussing them as well as Ricky demoing how you could actually use these in an application. [29:06]

Carl: Yeah. I will say, going back to a point a little bit about, you know, you shared the long thread and made an offhand comment about like, this could really be a blog post at this point. [29:23]

Like the post on Ricky's feed right before that is the, if you all promise not to ask me for docs or blog posts, maybe I'll explain a bit about why creating a cache API for suspense is so hard and it's, oh, I love that you're doing all of this, like social media outreach and everything, but like part of the problem that, part of the reason why nobody understands all of this and you have to do all the social media outreach is because there aren't static available resources for people to read. [29:31]

So it's like, ah, I love that this is happening and it's so good and so helpful. And there's follow up that's not happening that I think is really crucially important. [29:55]

Mark: That's actually been one of my running frustrations and complaints for a while. Ricky and I have actually had some back and forth on this, multiple times on Blue Sky. [30:03]

Yeah. Admittedly, I'm also not sitting here, honestly. I should probably start watching the docs repos so I have a better sense of what updates do happen. That one's on me, but to a certain extent, my, my knowledge of what's in the docs can get a little stale. Right. But Ricky has repeatedly complained that. [30:12]

People keep making the same wrong assumptions about what React has available, why the React team is doing things, et cetera. I've pushed them multiple times this year and said, you know, my answer is go write a docs page. Yeah. That covers exactly the topic you want and to have answered, and it answers it in exactly the way you want This material covered. [30:29]

A lot of people are still not gonna read that docs page, but some people who are already looking at the docs will see it. And when you run into yet another one of these questions on social media, now you have the pre-written answer and you link to it rather than having to answer it from scratch every time you see the same misconception pop up on social media. [30:55]

I, I wanna be clear, I, I am genuinely excited that Ricky has done so much outreach over the last year or so. Even just in the last couple weeks he was, he wrote dozens of tweets on both Blue Sky and Twitter around the threads related to the React innovation by default discussion. And I'm genuinely happy he's doing this much outreach. [31:18]

It's sort of taking Dan's place in that sense. But when your great answers are buried, 15 replies deep in a Twitter thread, no one sees them other than the person you're responding to. And that is the kind of material that desperately ought to be its own blog post, as well as these couple top level threats as well. [31:40]

And so I genuinely happy he's engaging. I would just love to see that material written up longer term. [32:03]

Carl: This is clearly a bit of a cycle, you know, like social, this has been true for years generally. So like maybe this is an opportunity for someone here listening to go through some of the, to go through these threads. [32:09]

Like if you're champing at the bit for an opportunity to have an impact on the ecosystem and on the industry, like this could be a pretty achievable way to do so. Like this content is out there, it exists, but not in a way that's discoverable. So like taking this knowledge that is being produced in ephemeral social media threads and then just like restructuring it, reformatting it into a markdown document and submitting a PR to react could be really effective. [32:24]

I, I'll throw that gauntlet down, like that is an achievable thing that I am probably not gonna do. [32:52]

Mark: People used to say that the real React docs was Dan Abramov's Twitter account, which he then deleted and all that info is gone. I don't expect blue sky to go down, but yeah, like if someone out there wanted to go through some of, you know, Dan and Ricky and whoever else's Blue Sky threads and pull out info and submit docs, prs like that would genuinely help the entire ecosystem. [32:58]

Carl: Yep. Right. And it doesn't need to be perfect first. Drafts are so good. First, the first draft is so hard and going from first draft to published thing is still a lot of work. But man, just getting a first draft out is often the thing that tips it over the edge into actually happening. Yep. I'll just say that if anyone's looking for something. [33:20]

Mark: Love the idea. Alright, moving right along. [33:38]

Server Components

Mark: A few different updates related to server components this month. [33:41]

React Router RSC framework mode preview

Mark: The biggest would be that React Router now has RSC support in their framework mode builds. So React Router, as I understand it now, has three different modes. There's sort of the, the traditional client side only, here's your list of routes mode, there's a somewhat more complicated data mode, and then there's the full blown full build framework mode. [33:44]

And so I believe they previously announced some RSC primitives available in data mode. And then I believe the framework mode is now taking those and expanding on them somehow to make it available for the full build. So, you know, again, having more RSC options available besides just next is a pretty big deal. [34:09]

And especially when it's built into something as widely used as React router. [34:30]

Carl: Yep. Love that. [34:34]

also middleware is now stable

Mark: They also announced that React router now has stable middleware support as well. Your routes can now have middleware. [34:36]

Krasimir Tsonev’s “Can I Use RSC Today?” support matrix and experimental Forket “RSC without a framework” build tool

Mark: Krasimir Tsonev, who is a React educator and has been around for a while, put up a nifty little support matrix called, can I use RSC today, where he tried to do equivalent bits of RSC usage and features across several different tools from next in, in Remix and Waku and various other tools. [34:44]

He was also very curious. I, I actually talked to him at React Summit in, in June, and I think this is what. And he was talking to a couple other folks, and I think this is what spawned him doing that deep dive where he was actually kind of bothered by the fact that server components require a framework. [35:07]

And so he went off and ended up implementing his own tool called for cat. Which is supposed to be somehow a proof of concept for using an RFC without an actual framework per se. So sort of a more primitive, granular client server separation build tool. [35:24]

RSBuild support for RSCs

Mark: Speaking of build tools, I saw mention that there is a set of plugins available that try to add some RSC support to the RS build, rust based bundler as well. [35:43]

Useful post on parallel and recursive route rendering

Mark: Finally, I also saw a good blog post that talked about techniques for doing parallel and recursive route rendering with RSCs. As Carl mentioned earlier, all this stuff is frankly outside of my experience, I've never tried to render, you know, RSCs much less do parallel and recursive stuff, but it clearly, people are out there experimenting with these things and that's good. [35:55]

Carl: Oh man. I'm looking at the blog post. You mentioned React server components without a framework and it's got a mention of Flux. Oh, throwback. Yeah. I mean we're Reactiflux because for about a six or eight months it was React and then you pair it with Flux and that was how you do UI and state management. [36:15]

So it's wow, throwback. That's a long time. [36:33]

All the NPM compromises and malware this month

Carl: Alright, little bit of a roundup on. Vulnerabilities and security incidents on MPM. There's been a lot this month. [36:35]

Mark: I think that the first one happened late last month, and we mentioned it briefly. Yeah. And then there was just like this constant flood of new compromises, new vulnerabilities, all kinds of packages being taken over, ranging from crypto miners to like full-blown credential stealing. [36:44]

It's, it's been pretty bad out there folks. [37:02]

Carl: Right? So last month. NX was compromised, which is discussed in this set of links that we have here. I'll send one at a time as we get into it, but yeah, so it, what we've seen has been everything from like pretty, there was a targeted attack that would do like intercede, crypto payments and sub out addresses for, you know, an attacker's wallet actually that had a small innovation in that category of attack where it would generate an address that was visually similar to the one that you had used to try and escape. Notice I heard that attack only got like $50 or like less than $500. I've seen some conflicting numbers, but like generally not effective, did not achieve its goals. [37:04]

But like it hit debug. Like it hit a package that I saw the security alert go out and I was like, oh, that sounds like something that I might use. And I checked. I'm like, yep, a bunch of projects on my computer were using that package. That was the one that got targeted with crypto interception, but previously, I think it was nx, was it last month, that we had the people who were stealing credentials and using AI to generate other code to steal credentials. [37:50]

Like, ah, that's the worst attack I've ever seen. And the only reason it wasn't worse was because of the limited scope of compromise. So like I was primed seeing that innovative, highly effective attack when I saw this massively widely distributed compromise of debug. And I have a little bit of egg on my face regarding this because I had pinged in the node Discord that I help operate saying like, oh, you need to look at this. This is awful. And it ended up not being as bad as I thought because that was a crypto miner, not a credential stealer. [38:19]

Mark: The attack itself seemed like a pretty big deal, and then it was almost sort of wasted on, well, it has to lead to you accidentally build a client side app that has the compromised version built into it. [38:54]

Carl: Right, they managed to successfully target one of the single most widely used packages. And completely squandered it by using it to execute an attack that had such limited application that they just didn't get anything. So like that's just straight up, like they screwed up, like they achieved a massive level of success and just like immediately fell on their face and did nothing with it. [39:08]

That's just a miss. Like that was just luck, that it wasn't worse than it was. [39:34]

Mark: But on the, on the flip side, the article that's talking about the ongoing supply chain attack did do a bunch of credential stealing, targeting a bunch of packages like [39:38]

npm package maintainer Qix

Mark: tiny color and a [39:47]

CrowdStrike npm Packages

Mark: bunch of CrowdStrike packages. Yeah. I don't know the extent of like what sites got hit because of that compromise. [39:48]

Yeah. But I believe that one's, that one had did a, done a pretty good job of finding credentials and publishing them on either, I think it was like either creating a new GitHub repo or creating a new specially named branch in GitHub repos to try to exfiltrate the credentials. [39:57]

Carl: Yeah. Oh, I was just reading this one actually. [40:14]

GitHub Actions npm Token Theft

Carl: It was, they had, they, somebody had added a line to the GitHub action that did, that would echo out the title of the PR and because it just did an un escaped string, you know, echo this. You could just terminate that and then run whatever you wanted. On the GitHub action, like, do not let any arbitrary person run whatever script they want in your seat. [40:16]

Like, oh man, that it's, that's pretty bad. And also, oof, this is CrowdStrike. Like, remember CrowdStrike and how they took down like every, like air travel around the world from another security problem that they had, and oops, they're a cybersecurity company where preventing attacks is their job. Oops. Yeah. [40:38]

I don't understand how they're still operating successfully. [40:57]

GitHub response

Mark: So, GitHub and NPM did actually put up a, a, an announcement saying that they're gonna be doing a lot of work to try to tighten up. Publishing of packages down the road, they're gonna be making changes to two fa it says they're gonna deprecate time-based passwords. [41:01]

That sounds like it's gonna end up being a, a big deal. I don't fully understand the implications yet. And, and they said they're gonna, you know, take time to roll these changes out. But that one seems like a big deal. We're also making and trying to apply more limits to tokens and work on better trusted pet publishing workflows as well. [41:20]

Interesting. [41:40]

Carl: Yeah. That's all important and useful, but like also, I don't know if there, if you just, if somebody opens a PR to your CI, that adds. A vulnerable un escaped string. Like it doesn't really matter how, what your authentication or publishing workflow looks like if that gets merged. Like you're vulnerable. [41:41]

So dunno how, dunno what you do about that specifically. But, okay. [41:56]

⚡ Lightning round ⚡

Carl: Let's hop into our lightning round. [42:00]

Porting Modern TypeScript to Run on DOS

Mark: I love a good article that just goes into absurd amounts of detail on a ridiculous thing that someone's trying to do, but they commit to the bit fully. And this one was, someone had a. JavaScript based game and they ported it all the way back to work on dos. [42:03]

Like why would you want to, I don't know, but apparently they actually made this work and I love it. [42:21]

Carl: That is insanity, and I also love it spiritually similar to Doom running in TypeScript types, just for no reason. Yep. Love. [42:27]

Cloudflare DDOSed themselves with a bad useEffect fetch

Mark: CloudFlare got into the news this month because they had a dashboard failure that cascaded, and believe it or not, it was caused by manually fetching data in a use effect that went into an infinite loop, which also means they weren't actually using like React query or anything like that. [42:35]

Oops. [42:55]

Carl: Yeah, I did hear like none of their services were affected. It was just the control panels that was taken down, so that's good. I also saw Guillermo Roush throwing some shade at the CloudFlare CEO after that. So, you know, drama post. [42:56]

A very lovely writeup of the evolution of css zoom

Carl: There's a cute post from Bocoup. There are web consultancy that's had a, a big impact on standards and web platform implementation details. [43:11]

So they, they've heard a cute blog post, the web's most tolerated feature looking into Zoom and how Zoom works. And it is kind, it's kind of cute. I don't know, just like it's a fun look at standards and like how. Cross browser implementation stuff works and how like, oh actually this like totally unstandardized thing just happens to work really well and everyone uses it. [43:21]

So, I don't know. It's cute. It's a cute post from people who are deeply involved in the standardization and implementation process, highlighting a case where like standards like just kind of didn't happen and it was fine. [43:44]

What You Need to Know about Modern CSS

Carl: Anyway, yeah, there was another good post from front end Masters who I, I've just always had a soft spot in my heart for front end masters because they were, that's the first platform that I learned react from. [43:56]

It was like a comparative class of Angular React and Ember, and I was like, oh, react seems nice. So like I owe them a debt to, you know, my entire career. So that's, it's cool. It's nice to see 'em still around and still staying on the ball. They published a post What you Need to Know about Modern CSS 2025 edition. [44:09]

Mark: And it was long too. It was long. [44:26]

Carl: It's big and I appreciate that because I've gone to a couple of conferences and I've seen talk from various people who are more, who work on CSS a little bit more. Una Kravets, I think is who I'm most specifically thinking of, who's wonderful and great and a great speaker. [44:28]

But like I'll see her talk about some CSS stuff and be like, wow, all of this is stuff that I've never heard of and CSS is completely different than what I've used in a lot of my career. That's awesome. And I don't know what to do about that. So this is a great post for me in that situation and going, ah, I need to catch up on like the last six years of stuff that I haven't really paid close attention to as it evolves step by step. [44:44]

So, great summary. [45:09]

Mark: We have a few different posts on browser behavior. So there was I and all from folks who have worked on browsers for a long time, I might add. [45:10]

Fetch streams are great, but not for measuring upload/download progress

Mark: Jake Archibald did one on fetch streams are great, but don't use them for measuring upload download progress points out that you still basically need to use XHR for that instead. [45:21]

Although there's discussion of adding some new options and callbacks to fetch that might accurately handle that at some point. [45:33]

Why do browsers throttle JS timers?

Mark: There was one from Nolan Lawson talking about why do browsers throttle JS timers? So you know, why does that time timeout zero actually be, why is it more like four milliseconds, et cetera? [45:40]

And basically it's because people rate bad code or either intentionally or unintentionally that can do bad things. [45:53]

“How Modern Browsers Work” deep dive, Addy Osmani

Mark: And then Addy Osmani did a pretty long post a, mid-level overview of how modern browsers work overall, going from, you know, parsing JavaScript in HTML in various ways to using GPUs to put pixels on the page. [46:01]

Carl: Yeah, it's funny to me to see, I don't know, I've just been seeing Addy Osmani and Nolan Lawson and Jake Archibald for so long. It's like, man, how great for them to stay on the top of the game for so long. It's great. [46:18]

Biome: Stress-testing WIP noFloatingPromises lint rule

Carl: One that I like here. I like seeing Vercel and Biome collaborated on stress testing, biomes new, no floating promises lint rule. [46:32]

I, again, have a soft spot in my heart For Biome, I was a initial backer of Rome back in the day, which was then forked after some maintainer shenanigans into Biome. They never really achieved the original vision, or have not yet at least, which was like unified, like linting compiling, you know, one tool to rule them all kind of thing. [46:41]

That it was called Rome because all paths, all roads lead to Rome, so it was trying to do all of it. They have achieved a lot of their goals, but not quite enough to really meaningfully claim to do all of it. [47:02]

Mark: It's become a pretty solid, a pretty solid formatter, but they never really managed to get into any of the multi tools sharing one a ST side. [47:15]

Carl: Yeah, right. Oh, that was it. It was because you know, you, you would have like Babel and ES lint and TypeScript and prettier and all of those, and all of them were independently parsing ASTs and then operating on. So like that's just a lot of wasted effort. So the, the goal was, the original goal was like one AST, all of this stuff talking to that will be an order of magnitude performance improvement. [47:23]

Mark: Mm-hmm. [47:44]

Carl: But anyway, so enough background, they have a new no floating promises rule because if you don't await or you know, respond to a promise, it can cause all sorts of super weird stuff. They say that, you know, a lot of engineers have campfire stories of floating promises taking down production, which is definitely true. [47:44]

I've definitely, a lot of the weirdest errors I've ever encountered track back to, oh, we didn't correctly wait for this promise to resolve, so this is it. This is a fun, deep dive technical writeup of how do you detect that promise. Has not been waited for. What does it even mean to return a promise when TypeScript has a built-in promise? [48:02]

Like construct? It's a good read. It's a good deep dive. [48:23]

Mark: I should point out that the article was written by Dmitri Metropolis, who just got done organizing Squiggle conf and is also the person who did Doom in Typescripts. [48:27]

Carl: Oh, it is, Love Dmitri. Love that. [48:34]

Bun: How bun install is so fast

Carl: There is a good deep dive here into Bun Install and how it's so fast. [48:37]

They say on average it runs seven times faster than MPM and 17 fast times faster than you yarn. It's a large post and it's got a lot of real deep benchmark stuff. Mm-hmm. [48:43]

Mark: I think Lydia Halley wrote that one actually very well written post. Lot of detail. [48:53]

Carl: Wait, was she on React? [48:58]

Mark: I believe she was working for Vercel and left, and I think she actually just joined Bun as a DevRel. [49:00]

Carl: Great. I'm just always here for like a deep technical dive. So many, so many blog posts are just a little bit more surface level, so seeing something more like a white paper, a technical writeup, I just love I, it's such a good window into the real challenges that different people around our industries are encountering [49:06]

Styled-Components fork for perf and React 19 compat

Mark: for folks who are still using style components, the sanity company actually forked the existing now unmaintained library and made a couple major updates. [49:23]

One, to try to optimize the overall performance and another to try to provide React 19 compat. They say they are not maintaining these forks per se, but they have done the work because they themselves still relied on it. And so they've made those, they've published those so that other people can benefit from it. [49:35]

So if you're still work, still using style components, you may want to take a look at that. [49:57]

Vite SSR: Custom getStaticProps

Mark: Also saw a nice little post that talked about building your own get static props alike equivalent if you're using Vite for SSR. [50:02]

Dominic Gannaway’s new framework Ripple

Mark: And in the frameworks that are not actually React, but related category. Dominic Getaway, who originally created a React Delight called Inferno and was on the React team for a while, has built his a new independent framework called Ripple, which tries to pull together some new ideas around template compilation and use of JS syntax, but in a way that's different than React. [50:11]

Remix v3: MJ hints “iframe-like async primitives”

Mark: And then Michael Jackson and Ryan Florence continue to drop assorted hints online about what their Remix version three is going to look like. Michael's latest tweets are saying, what if he could just sort of use iframes or iframe like behavior for async loading? And I really just want to see the actual examples at this point, but they're dropping hints about what it'll be like. [50:35]

And oh, the plan is to actually show stuff off at Remix Jam, which I think is coming up next month. [51:00]

Carl: Yep. I am skeptical. I don't know, I, I appreciate the broad strokes of iframe, but the actual security constraints of using iframes is, that's just not, they're not good. It's not pleasant. It's not, you know, that's very like 2003 era web development and we stopped doing that because it kind of sucked. [51:07]

It was hard to make good experiences. If it's not literally in I frames, that's very different. So maybe it'll be better than that. There's an argument to be made that what he is talking about shares significant overlap with the islands style micro front ends. So, I'm not checked out. I'm curious, but I'm skeptical. [51:27]

Unfortunately. It sounds like Mo's having like significant internet challenges in his office right now. So I'm gonna, I'm gonna pull in some of the stuff that would've been, you know, that he wanted to talk about. [51:49]

React Native RFC to remove Old Architecture

Carl: There's been a RFC for React native, for a plan for actually removing the old architecture, the previous way of serializing communication between the JavaScript engine and the native layer. [51:57]

So it's not only, not only is the new architecture default, they are now proactively communi or they're proactively planning how to get rid of the old architecture entirely. Well, that's great. That feels like a big step towards 1.0, like we were talking about before. [52:13]

Cloudflare’s new “Cap’n Web” RPC; GraphQL alternative?

Mark: So CloudFlare announced a new tool called Cap'n Web, which is a RPC system meant for browsers and web servers. [52:28]

And this was created by the same person who, by Ken and Varta, who had created a couple other serialization libraries, one called Capin Proto, and Capin. Proto works with both c plus plus and JavaScript and possibly a couple other languages. And Capin proto is sort of a follow on that's specifically meant for use with web and can be sent back and forth using just plain JSON. [52:38]

I believe the article actually kind of pitches it sort of as an alternative to GraphQL in a way. It actually does a funky little thing where if you make what looks like an initial request for an item and then you get back a promise for that response, you can call map on the promise and. Essentially map over what will be the list of items and say, for example, gimme details on all the child items by their id, but then it'll actually get batched up into a single request. [53:05]

So there's some technical trickery going on there, but it sounds like it's meant to simplify both making a request back and forth and managing the overhead of what would've potentially been many independent requests as well. Thus, the comparison to like a GraphQL style thing. [53:42]

Carl: Interesting. And also, I'll shout out. [53:59]

You know, Cap'n Proto here is spiritually very similar to the challenge, it's solving a problem that's spiritually very similar to the new architecture and React Native, like basically, you know, this RPC is going instead of going across like a native JavaScript layer, like a new React native, this is how do you do a similar type of communication between systems across the network boundary? [54:02]

And the challenge is like the reason you would use something like Cap'n Proto or Protocol Buffers, which you know, there's kind of competitors there is because the serialization costs and the volume of communication if you're using JSON, is just much higher, like converting it into a string. It's basically a string versus a binary data format. [54:25]

Like the, one of the problems with JS is that you're encoding not just the data, but also the structure. You're saying, here's the object, here's the keys, here's what it looks like. And that's. That's information. You know, if you're sending that information across the wire, that's extra effort. If you already have two, two agents on opposite ends of a network and they say, we agree that our communication is in this format, then you don't need to send the format across the wire. [54:46]

So that's the fundamental like reason why you might use one of these tools instead of just sending JSON over HTTP and yeah, it's interesting. This is, it's pretty cool. [55:16]

Expo UI: Building SwiftUI apps

Carl: Cool. The Expo had an interesting post talking about using Swift UI in React Native, so that, that's pretty cool. Like being able to directly, if you're in, only, if you're only targeting a native environment, being able to. [55:26]

Exclusively use native primitives is like a huge win. Like if you don't, you know, it's always good to remove compatibility layers if you don't need the compatibility. So that's really cool. It's it, this looks pretty interesting if you're doing stuff on Mac Os or like Apple TV or things like that. [55:40]

TanStack DB: An interactive guide

Mark: So the TanStack folks recently announced a new package called TanStack DB, which is supposed to be a smart syncing layer on top of TanStack Query that can do things like in-memory filtering and querying of data very efficiently. [55:57]

And so there was a neat post that was an interactive guide to TanStack db and discussing some of the options and some of the things you can do with it. [56:13]

TS 6.0: may switch to strict options by default

Carl: TypeScript version six may switch to strict options by default. This is, [56:21]

Mark: hallelujah. [56:27]

Carl: Yeah, right. What a long time coming. Like I have treated this as a deep, you know, this has been step one of setting up a new TypeScript project for me since I've started using TypeScript. 'cause it's always been the best practice. So I love that they are discussing, switching this over. Yeah. It starts almost a decade ago. We began to add certain options beyond, no implicit any in strict no checks. So, yeah, like almost a decade ago. So that's the, that's cool. TypeScript 6.0 will assume that dash dash strict is on unless explicitly disabled, which means specific settings like strict no checks and no implicit any will be enabled unless it's turned off explicitly. [56:28]

Woo. Cool. No implicit any is if you don't turn that off, like you're not really using Patrick, like it's just sparkling JavaScript. So that cool. Love that. Love to see this. [57:05]

Mark: There's a lot of debates over the nuances of what that concept of turning on strict by default actually means. But I would assume that something along those lines would land and yeah, it's way overdue. [57:16]

Shopify’s RN New Architecture migration

Mark: Alright, last couple ones and then we're done with the not so lightning. Lightning round Shopify put up a post talking about their migration to the React native new architecture and went through both some pros and cons and pitfalls of what that process involved. [57:28]

The Bloat of Edge-Case First Libraries

Mark: And then the last one is from James, who has the really funky username that I'm not even going to try to pronounce, but he's been working as part of the E 18 E ecosystem speed up process. [57:42]

In fact, he's the person that I did a stream on a couple days ago where we talked about my work to make the Immer library faster. And his post looks at like, gives an example of, let's say you have a math clamp function that takes some arguments. But you don't want it to crash if someone does something stupid like passing in, you know, a string instead of a number and next thing you know, like two thirds of your function is just validating the inputs before it actually does anything. [57:54]

And he argues that, you know what? This actually ends up being kind of a waste of space and execution time. And that to a certain extent, if someone passes in bad input, that's their problem and not your problem, which I can sort of get behind. [58:24]

Carl: Yeah, interesting. That makes a lot of sense. It's kind of the right, it's a challenge between sharing code and doing it inline how when you start trying to do it inline, you end up re-implementing a lot. [58:40]

Conferences (React, Javascript)

Carl: Cool. Let's talk about some conferences. [58:51]

React Alicante Oct 2-4

Carl: We have in like three days, two days. React Alicante in Spain, October 2nd through fourth. [58:53]

Mark: I will be speaking there. I'm flying out on Wednesday. [59:01]

Carl: Woo. And then you're fly. And then you're flying [59:04]

Mark: all the back and then flying all the way back across, across the world for to attend React Conf. [59:07]

Carl: Yep. I'll be there too. [59:11]

React Conf is back, Oct 7-8 Las Vegas, NV, USA

Carl: So yeah, react Conf in Henderson, Nevada, right near Vegas. I'm actually gonna be driving from San Jose, so like if you're in the Bay Area a couple days before the React conf, lemme know. I don't know. I'm gonna go hiking, so, we'll, it's gonna be an adventure. [59:13]

Remix Jam, Oct 10, Toronto ON, CA

Carl: Then a couple days after React Conf, Remix is doing their own conference in Toronto, the Remix Jam. [59:29]

So yeah, maybe. We'll, we will see. It'll be interesting to see what they come out with. Yeah, I'm curious. Yeah. [59:37]

ViteConf Oct 9-10 Amsterdam, Netherlands

Carl: Anyway, coincident with that, ViteConf is happening October 9th and 10th in Amsterdam. That'll be cool. [59:43]

Love to see what they come out with. [59:50]

JSConf North America Oct 14-16 Chesapeake Bay, MD, USA

Carl: JSConf is doing a couple of events all over the world actually, so they're doing JSConf North America October 14th through 16th in Chesapeake Bay, Maryland, [59:52]

JSConf Chile Oct 24-25 Santiago, Chile

Carl: and they're also doing re JSConf Chile, October 24th and 25th in Santiago, Chile. [01:00:03]

React Native London Oct 30-31

Carl: We've also got, after that React Native London, October 30th and 31st, [01:00:10]

Mark: and Mo runs that, so you should totally be there and support him [01:00:18]

React India Oct 31 Nov 1 Goa, India

Carl: after that, there's React India October 31st and November 1st, [01:00:22]

Wey Wey Web Nov 17-18 Malaga, Spain

Carl: and then the Wey Wey Web, I think I'm pronouncing that right. It says it's a yay, yay conference, international conference for ux. But yeah, that's happening in Malaga, Spain, November 17th and 18th. [01:00:26]

React Summit Nov 18-21 New York, NY, USA

Carl: And then we've got React Summit happening in New York, November 18th through 21st. [01:00:39]

So that's cool. We'll see. Maybe I can make it to that. It's in my hometown, so Yeah, that'd be great. [01:00:43]

React Advanced Nov 28th, London UK

Mark: And then React. React Advanced is November 28th, all and although it's uh, inconveniently the day after us Thanksgiving this year, they had done it in late October, previous years, and I think since they're not doing React Berlin, they bumped the schedule for React Advance to be sort of in the middle where those would've been. [01:00:48]

Outro

Carl: That's everything we got for you this month. Thank you so much for joining us. We'll be back on the last Wednesday of the month probably, although we had to reschedule this month again, sorry. Or we will be back in your podcast feed just as soon as we can. We gather sources from, actually this month we pretty much only gathered sources from Reactive Fly. [01:01:08]

It was a good month for, you know, us staying up to date. Yeah, generally we do subscribe to this week in React, which is a great source. Follow lots of people on Blue Sky and Twitter, the React JS subreddit and just, you know, generally all over the internet. We try and stay in touch. If you see anything that you think that we should be aware of, definitely post. [01:01:25]

Actually, you should just post it to the Tech News and Reads channel here. I would love it if we could have some more chatter going on there and it really does help us stay on top of things and helps me understand it. If, you know, if you post a link and then you and somebody else have a conversation, I will read that and it will inform my opinion. [01:01:46]

So yeah, it's a great way to do it. If this is a show that you get value from and wanna support, best way to do so is by reviewing us on whatever platform you listen to or tell your friends and coworkers about it. So, you know, send 'em a link. Cheers. Thanks so much for listening. [01:02:02]