TMiR 2025-11: Cloudflare outage, ongoing npm hacks, React Router is getting RSCs

Transcript from Thursday November 27th, 2025

2-vcarl: Hello! Thank you for joining us for the November edition of this month in React. As we recap what's going on in the React, React native and web ecosystems, we're coming to you live from Reactiflux, the place for professional developers using React. [00:00:00]

Intro

2-vcarl: And I am Carl. I'm a staff product developer and freelance community leader here at Reactiflux where I do community programs like these events and build tools to help keep the community operating. [00:00:13]

1-acemarke: Hi, I'm Mark. My day job is working at Replay.io and doing various time travel debugging and information architecture things outside of that I, I work on Red Ducks. I complain about the React docs and I collect links and I go rewrite libraries, Limmer. [00:00:22]

2-vcarl: Mo unfortunately could not join. He had a fire drill happen, a metaphorical fire drill, happen at work like an hour before we started. But generally we have Mo, who is head of mobile at Theodo and is very active in the React native community. Kind of sad that he had to skip out this month because he just did React Native London, and I was hoping to hear how that went. [00:00:39]

New releases

2-vcarl: But yeah, let's get straight into it with some new releases. [00:01:00]

BetterAuth 1.4

2-vcarl: First off, we've got better off 1.4. I actually use Better Off now. Woo. I had been excited about it for a while because I don't like authentication. Libraries generally like stuff like Passport or what, you know, even clerk or the SaaS businesses, just like none of them. [00:01:04]

I didn't like them very much, so was very pleased to see an open source library that looked to cover many of the bases that I want and can confirm after using it that it does. So I'm excited to see Better Off 1.4, which is the first release since I believe July when it did 1.3. A couple of quick highlights from it. [00:01:20]

It's got stateless off. So you can do sessions without a database just by not giving it one, which is nice. It's also got SCIM provisioning for identities in multi-domain scenarios, which is cool. Also, some other little details like database joins and custom state for OAuth flows. But yeah, just auth is a shockingly deep subject when you actually start dealing with the nitty gritty weirdnesses of it. [00:01:40]

And I have generally found most open source projects trying to support authentication to be, to leave something to be desired and better off leaves the least to be desired of the projects. I've tried, so Love it. New version. [00:02:06]

1-acemarke: I have thus far managed to stay away from dealing with auth at all in my career, and I would like to keep it that way. [00:02:20]

2-vcarl: Yeah, that's not a bad call since I haven't been able to avoid it. I went a little bit deep on it and I don't hate that either. It's interesting. It's fascinating. Actually. I don't know, one of the vague. Startup ideas in the back of my brain is related to authentication and identity management, which could be cool. [00:02:28]

I don't know, maybe I'll do something with that eventually. [00:02:44]

Immer 11, RTK 2.11

2-vcarl: Mark, I want you to unveil your magnum opus. [00:02:47]

1-acemarke: Happily. So I talked about this a bit last time, but Redux Toolkit relies on Immer for immutable state updates. It always has since day one. We've gotten various complaints over the years that, you know, Immer is kind of slow, but we've always said that we prefer the fact that it eliminates accidental mutations, makes reducers easier to write. [00:02:50]

Of course, we want Redux toolkit to be fast, but we also want things to be correct and users to not have bugs. So I'd done a little bit of perf investigation into Immer like a year ago. Saw that it had gotten slower, filed an issue. You know, it was kind of left there. And at the start of September, I myself dug in and started trying to see if I could optimize ER's performance. [00:03:11]

And I spent well over a hundred hours collectively across September and October, deep diving into ems, codebase, comparing it to other libraries, understanding how it worked, and trained to do a bunch of performance optimizations. And so ended up filing a few different prs, Immer 10.2, shipped last month with some small tweaks, and Michelle West Rate just merged a big architectural change and released it as Immer version 11 just a couple days ago. [00:03:34]

And then I was able to put out RTK two point 11, which picks that up. So free performance wins for Redux Toolkit and Nier. [00:04:04]

2-vcarl: Heck yeah. That was what was the average speed up? [00:04:13]

1-acemarke: The current builds average about 20 to 25% across all the different benchmarks, varying by scenario. And then there's another outstanding pr, which adds an optional array methods override plugin, which drastically speeds up array methods. [00:04:16]

2-vcarl: Heck yeah. That's awesome. We love a core performance improvement and I, I wanna shout out the ecosystem performance. You know, I don't know, [00:04:34]

1-acemarke: E 18 E folks are awesome. They have been doing a ton of work to clean up large dependency trees and slim down packages and remove dependencies across a wide variety of tools. [00:04:43]

Yep. [00:04:56]

2-vcarl: A stat that I believe we'll talk about later, I saw in general ecosystem commentary. Yeah. I guess in the NPM supply chain fact that we'll talk about later, a a a stat that came out of a blog post from that was that the average JavaScript project pulls in 683, I believe in, was it transitive dependencies? Just like, yeah. It's a lot. So when you've got that many dependencies, performance of the ecosystem is challenging. Yeah. [00:04:56]

1-acemarke: That doesn't surprise me. I know that. React app. The last I saw it defaulted to about 1500 dependencies, largely because of Webpack, et cetera. Vite's obviously a lot fewer, but still that's, that's not great, just for a whole variety of reasons. [00:05:21]

2-vcarl: I guess teaser for y'all. Later, towards the end of the episode, we're gonna talk about web ecosystem and there's been some blog posts talking about like. AI and how it defaults to building React instead of using the web platform and how do we promote the web overreact, things like that, which I don't know, it just feels that we just started bleeding into that topic, and so we will get much more deeply into that later in the episode. [00:05:37]

Storybook 10

1-acemarke: Next release. So Storybook 10 came out a few different big points there. One of the biggest is that it's now ESM only. They've removed all the, the common JS artifacts, so they've shrunk the install size and they've also drastically shrunk the dependency chains as well, as well as some improvements to things like the mocking and some of the storybook formats. [00:06:00]

0.1 version of Remix team’s “event interaction” package

1-acemarke: And then one other release of note, the Remix folks are continuing to work on Remix V three after the initial demo and announcements, and they're trying to build it, as I understand it, with a lot of smaller reusable packages. And they just put out the first 0.1 alpha of their. Event interaction package, which is providing an abstraction for being able to compose events and listeners and behaviors together looks interesting. [00:06:22]

I'm not gonna claim I understand like exactly the benefits this comes, but nice to see the progress there and I suspect that a lot of folks are gonna get some use outta this. [00:06:49]

2-vcarl: Yeah, I'm reading the syntax here and it looks like a different way of adding event listeners to DOM nodes, which, sure. I don't know, there's weird quirks and certainly the Remix team and you know, Michael Jackson and Ryan Florence specifically have shown, have demonstrated a great willingness to jump into what many people consider solved problems to reexamine from first principles. [00:07:00]

So, I dunno, they've, they've done that, they've done that repeatedly with their own solved problems of data loading in routing. The interaction between data loading and routing. I feel like that's one of the bigger complaints about React router is that they keep reexamining that same question. So I don't know. [00:07:25]

It's interesting that they do have interesting things to say when I've seen them reexamine, quote unquote solved problems. So I'll, I'm curious. This looks a little strange. It looks pretty divorced from the DOM structure, so if you just like on input element and then add a bunch of listeners for it, that's curious. [00:07:41]

Anyway. Yeah. 0.1 release, we'll see what they come out with. [00:08:00]

Main content

2-vcarl: Okay. That's all the new releases we got so far. Let's go into some main content. [00:08:04]

Ecosystem panel discussion of React Foundation at React Summit NY

2-vcarl: First off, we want to talk a bit about, yeah, mark, you are on an ecosystem panel at React Summit this month. [00:08:08]

1-acemarke: So let's see. Addie has money was moderating. We had Seth Webster from the React team, React Foundation, Shaundai Person, Amy Ner, Nicholas Gallagher, and myself. [00:08:15]

A lot of the discussion was us asking Seth Webster questions about, so this React Foundation thing, like how is this actually gonna work? What does this actually mean for the React team and the project and the ecosystem? There is a video for the panel. It's not unlocked yet. I have access to it because I speak at GI Nation events, but the video should unlock within a couple weeks, I think a a few different points that Seth made during the panel itself. [00:08:25]

And then I had a chance to have a follow-up discussion with him afterwards and. There's a few different very interesting p pieces of news about how the foundation's going to work and what their plans are. He talked a bit about some of the, the funding process. So, you know, large companies pay, you know, a good chunk of money to be members. [00:08:55]

The, the existing. Board member companies have already paid up for like three to five years, and it sounds like he'd actually been working on putting the foundation together for over four years. Like this was a very long term kind of a process. [00:09:16]

And they're hoping to do a number of different things with the money. They want to hire some additional engineers. And he even said some of that would be spent on having engineers triage the issues. And if you've ever looked at the React repo, you know, that's a thing that they do not do very often. So even something like that sounds good. They want to hire some more people to work on the actual docs and they're hoping to give money out to communities in some way. [00:09:31]

Don't know details on that, but [00:10:00]

2-vcarl: Tell me more! [00:10:02]

1-acemarke: Exactly. Another data point. So a lot of the plans have to do with the development process of the React project itself and transparency around that. Apparently they were even hoping to launch the foundation like a year and a half ago. And then they realized that like, "our own in day-to-day development processes aren't ready for that. We need to dog food the processes ourselves first so that we're more ready when the foundation goes live." [00:10:03]

And so some of that was actually having docs and plans as new features are being developed or treating things in kind of like a, you know, TC 39 staged process. Approach, but one of the biggest things that Seth told me directly was that up until now, the React team has had, you know, their, like their weekly status meetings and those are purely internal. [00:10:36]

First off, it was just all the React team working at Meta and then it was, you know, meta plus versal. But those meetings have always been internal, private, and non-visible. And Seth said that they eventually want to literally open up the weekly React team planning meetings to the public even as like a, like a Zoom call with no password. [00:11:00]

And that eventually, like designated community reps would even be able to actively participate. In those discussions. So that's a radical change in the development of React itself. He also said that they're planning to resurrect or like completely redo the RFC process, which frankly was kind of dead from the beginning. [00:11:24]

It was where random people from the community posted ideas that got ignored and the React team posted, finished things that they planned to ship and then people argued over the naming and the React team ignored that. So like historically, the RFC process was pretty much irrelevant to actual React development. [00:11:46]

Now they're talking about making it like a real meaningful discussion and part of the planning process. Now again, like do I know how this is gonna work out in practice? No. But I can see the amount of effort and the intent. Behind the foundation and the plans that they're talking about. And even if it doesn't end up going exactly as they, or we would hope, I see good faith and good intentions behind all the work that they're trying to do around the process here. [00:12:04]

So I'm actually very, very excited about this. [00:12:36]

2-vcarl: Yeah, that's interesting. Oh, I got a lot of thoughts rattling around my head. 'cause that's a lot of stuff that I've looked at trying to contribute towards the solution of, yeah, I don't know. It's, I fundamentally, I feel like the problem they're dealing with is that a lot of people care about the outcome, the output, what they make and what React is. And not a lot of people actually have like the context and the background to like meaningfully contribute to the advancement of that goal. [00:12:39]

You know, to respond to what you just said about like their motivations and their what they want to do. I don't think that's ever really been the problem, they've always had good intent and I even think a pretty clear eye picture of what the problems are. But I think the problems are really thorny and complex and the solutions to them are non-obvious. And even when you have a good solution idea, executing it in a way that is effective and that operates on the kind of like timescales that React is around for is just really challenging. [00:13:08]

Like it's, you know, anyone can spin up a process and run it twice and you know, maybe that, like you do, you call for comments and you run a community discussion and round tables and whatever, but like that plays out over the timescale of like weeks and months and React seems to plan on the order of years and is, now has existed for a decade. [00:13:42]

So, you know, with like there's possibility for its scope to expand from thinking in terms of years to thinking in terms of, I don't wanna say decades, but that's the next unit of time. That's the next order of magnitude. I hope they can achieve their goals. I am looking forward to seeing some more roadmap, transparency of some sort. [00:14:05]

Actually that'll be really great for us, for you and I. That'll be great. Yep. That'll be a great source of signal that we can then pick apart and analyze to surely, to much to their chagrin by way of drawing attention to things that are high context [00:14:23]

1-acemarke: as opposed to like stalking the open PRs list. [00:14:40]

2-vcarl: Yeah. Right. Cool. Nice. Love that. [00:14:43]

React Concurrent Stores: Polyfill, React-Redux POC

1-acemarke: So on that note, another item that I've personally been involved in is the work on the upcoming React Concurrent Stores API. So when React 18 came out, the React team included the Uyc external store hook as the official built-in way for third party libraries like Redux, Zein, Jo Tai, whatever else to integrate into React, take an external state update, turn it into a React re-render, and it worked. [00:14:46]

But it also had a very intentional design limitation that if you do an update in the middle of a paused React render, you know, something transition like then it bails out of that and just does a complete top to bottom render. So you're kind of throwing away some of the benefits of React, being able to pause itself. [00:15:13]

And that was because they, they really didn't have a better idea for how to do that kind of interop. So this concurrent store's API is supposed to be essentially a new equivalent to use sync external store, but concurrent transition compatible. And Jordan Eldridge, who's on the relay team, has been working on the design and initial prototype IMP implementation for this. [00:15:32]

And so he put out a polyfill package that roughly implements the prototype as a standalone library. And then I've been talking with him about, you know, here's what Redux would probably need to make this work. Here's our, our requirements for this. And so I was able to then take his proof of concept package and put up a draft PR for React Redux that just swapped out our used selector implementation to use that instead. [00:15:57]

And it basically worked, I mean, just the one test file found a couple edge cases, but like most of our tests passed, we're not doing anything transition related in our tests. But it's good to know that like your baseline standard behavior works. [00:16:25]

And this also turned up several more things we'll have to figure out, like, quality checks and how do you handle selectors throwing errors, and we're talking about when can React safely, call selectors, can it delay it due to batching and things like that. So also very excited to see the progress being made on this API. A lot of people have asked for external state transition compatibility, and so this is going to be a big deal for the ecosystem. [00:16:39]

2-vcarl: Interesting. Cool. I'm just trying to put this in a little bit of context for myself. So this is a, an exploration of an API for a concurrent store that they've indicated intent to ship eventually. Is that right? Mm-hmm. [00:17:08]

1-acemarke: Yeah. So basically a, a new equivalent of useSyncExternalStore, but minus the sync restriction. [00:17:22]

2-vcarl: Got it. Okay, cool. Interesting. You called it a poly fill, and I see in the blog post it's labeled a pony fill, which I had to refresh my memory on the distinction; a poly fill fills in a gap in the platform transparently, and a pony fill offers the same functionality, but as a standalone module that you have to import. [00:17:30]

There you go. Now you know. [00:17:50]

React Router and transition usage

1-acemarke: So one more item kind of related to that. At React Conf, Ricky Hanlon announced a new Async React Working Group to provide support to the, you know, the community and the ecosystem on, you know, improving the React docs around async behavior, helping libraries get set up to use these methods. [00:17:52]

Matt Brophy and Ricky discussing nuances of behavior, use with React Router

1-acemarke: And so Matt Brophy from the React router team had a good discussion with Ricky about how they're trying to handle using transitions in React router. So there was a, a good technical discussion about the nuances of behavior. And then the React router team also put out a pre-release version or unstable option to enable some of the transition behavior as well. [00:18:08]

So starting to see some adoption and this ties into the React team wanting to see libraries pick up these behaviors like transitions and action props and, and build them in. I will say that I had a couple discussions at JS Nation React Summit where some people were questioning whether making the entire ecosystem change semantics and behaviors and add props to make the React team happy was gonna be a good idea or feasible, but we'll see. [00:18:33]

2-vcarl: Yeah, interesting. I see a bit of why they, why the core team desires that. Transitions are definitely like. My understanding of the core team's incentives and what they care about is ability to use the platform and things like that. So given that like transitions are a part of the platform and they are interested in allowing people to take advantage of platform improvements, I understand why they would message, "in order to use this, the entire ecosystem must make this change to the patterns they use for compatibility reasons." [00:19:03]

But that is very, I don't know. That's a big challenge. It's herding a lot of cats who don't necessarily, aren't even necessarily aware that there's an attempt to herd being made. [00:19:38]

1-acemarke: If you watch Ricky's talk from React conf, you know, he, he demoed switching from like a bunch of manual use effects and loading states to suspense and transitions and then he pointed out, and so now you have a much better experience, but you also had to do, you know, call start transition and all your click handlers and so on. [00:19:49]

There's even some painful nuances there because start transition is based on setting a flag internally for the current event loop tick. If you have a callback that has an await, you leave the event loop tick. And if you then want to do another state update after the await, you have to call start transition a second nested time. [00:20:05]

And Ryan Carniato actually pointed out to me that like Ricky has repeatedly messed this up in his own demos, it's a very foot gun prone behavior pattern. And so the combination of, like, you currently have to call, start transition yourself, plus trying to get the patterns right, is a good argument for let's just build this into all the libraries. [00:20:29]

But that takes time and effort and coordination. [00:20:53]

2-vcarl: Yeah. Right. Like that was one of my big takeaways from Ricky's talk was, oh, this looks hard. Which is not the best takeaway if you're trying to convince the whole ecosystem to move on to something. [00:20:56]

1-acemarke: There is a lot of complexity in mental model of React and the kinds of apps we're trying to build. [00:21:08]

And both the fact that you now need to keep track of additional API methods that you have to call and the semantics and when you're supposed to use them. And the fact that your, your state is now kind of in multiple Schrodinger's box, multiple versions at once. It's, it's definitely a lot of additional mental overhead. [00:21:15]

2-vcarl: Yeah, right. I'm just looking at, in this GitHub thread that you linked, Ricky says, you know, oh, I think there might have been some confusion. Here's how you do it for navigations and it's, you know, function, navigate to A URL that has start transition, which, you know, wraps set router state, which then wrap, you know, it's argument is a function that I guess returns A URL. It's a thunk for set router state in start transition, in navigate. I don't know, they're like, that's just complicated. Like what? Why are we wrapping this with so many different functions just to navigate? That's uncomfortable. It feels like the wrong API in some way. You know, like it an API should obscure complexity and this does not obscure the complexity. [00:21:35]

So, interesting. I want to be able to take advantage of transitions in apps. 'cause that's super great if you can just like easily convey that you are here and you're about to go here. Instead of just going there, like you get a lot of really powerful things that you can do for user experience and, you know, whatever, all sorts of stuff, if you communicate the transition instead of just updating the current state of your app. [00:22:17]

But yeah, I don't, I, I'm not sold on this. I'm not sold on one I'm seeing so far. [00:22:43]

1-acemarke: Okay. Moving on to the next related chunk of topic. [00:22:48]

The State of TanStack, Two Years of Full-Time OSS

1-acemarke: The Tan Stack folks have a bunch of updates that they've put out both blog posts and versions. So Tanner put out an article on the state of Tan Stack as an organization and his own work as a full-time open source maintainer for the last couple years. [00:22:53]

Also, again heard, you know, heard some of this from, from him directly at a React summit loosely. He himself has been full-time supported open source for the last couple years, sponsorships to the TN stack org. Tan Stack Libraries are, you know, as we all know, very, very widely adopted and certainly query is the standard Fritz thing at this point. [00:23:13]

Router and is picking up a lot, A lot of popularity start is almost 1.0 and he's hoping to be able to start to bring in some part-time or even full-time. Uh. People to hand stack the company in the near future, essentially other. Current maintainers for various stand sand stack libraries who would then be able to potentially switch to doing that as their actual job. [00:23:34]

So essentially he's been fortunate enough to have this work out for him and he's hoping to share that ability with other people working on the projects. [00:24:00]

2-vcarl: Yeah, I see. He says monthly sponsorships for 12 core contributors and short term contracts for another three to five people. I guess that's not clear what monthly sponsorships means. [00:24:09]

I, my assu, my assumption there would be like their, maybe not full time, but getting like sign, you know, significant compensation. But that may not necessarily be true. [00:24:20]

1-acemarke: I don't know numbers, but I think at the moment the others are doing open source and they're full-time and getting some, some stipends and in the next couple years he's looking at actually hiring some of them. [00:24:30]

2-vcarl: Cool. Love that. That's super hard. Building revenue so that you can actually support other humans is actually really challenging. I really like this blog post about, you know, Tan Stack for two years. I like this line. You know, building a full stack framework is hard. I knew that from watching other teams do it. [00:24:42]

Most of them had something I didn't. Capital Next Gatsby Redwood Remix all had funding companies or acquisition paths and that that definitely is something that feels very different about Tans stack. It feels very much like he couldn't not do this. Like he just had spent several years working in this problem space and solving his own problems with the freedom to publish them so that other people can take advantage of his work. [00:24:56]

And then got to a point where it just made sense to invest more effort and take those a little bit further than they could go. Absent that. Level of dedication I, which i, I love. That's just like, that's, I don't know, finding that kind of work to do for yourself is what I've been looking for. And it's really hard to find, and I love that Tanner Winsley has apparently found it. [00:25:20]

Yeah. And also having 16 partners doing sponsorships is also great. Like that, that, that may not be capital, but that's, that's great. That's nice. Having tried to find sponsors myself, like getting 16, it's like, oh shit. Good job. That's awesome. [00:25:43]

TanStack DB 0.5

1-acemarke: Tan Stack DB is a new work in progress package largely being worked on by Kyle Matthews, formerly of Gatsby, currently of electric SQL, that is meant to be kind of like a half a sync engine layer on top of another data source. And so like one of the common usage patterns for that would be you wrap it on top of your 10 stack query, you know, API definitions. And so maybe you've got some endpoints for fetching. Post comments, users, et cetera. [00:25:57]

But then it presents like a sync engine like interface on top of that, and it's got a bunch of data flow analysis baked in so that it can do things like partial fetches or only re fetching, you know, certain pieces of data, joining, essentially presenting like a normalized facade layer over the individual endpoints so that they act like they're unified almost as a like a replacement for a GraphQL style API. [00:26:27]

And so they've been working on this and it has integrations with Tan Stack Query and then Electric SQL and a few other data packages. And Tanner pointed out to me at React Summit that it really just needs an adapter layer to be able to connect to another library. And I could totally build one for RTK query. [00:26:54]

And so I was actually briefly playing with that on the flight home. I haven't had a chance to push it further, but I'm actually, I'm actually very excited to play with that more myself because like Tan Stack query, we made the decision to make RTK query non normalized. It just caches the response from the server. [00:27:12]

And so if this essentially let us make a normalized layer on top of our own library without us having to make any further API changes. That's very interesting to me. [00:27:29]

2-vcarl: I'm also thinking about, you know, this is from Kyle Matthews who did Gatsby, which, you know, notoriously exposed a GraphQL, you know, layer on top of whatever data sources you wanted to give it. [00:27:41]

So just, I'm thinking about how, how much of Kyle Matthews work could be described as providing query abstractions over arbitrary data layers with data connectors. [00:27:54]

1-acemarke: That's a good point. I, I had, I hadn't even drawn that connection that this is actually very related to his prior work. [00:28:05]

2-vcarl: If you described this at a certain level of abstraction, this sounds just like GraphQL, Relay, Gatsby, a bunch of other stuff. But I do see the niche that it occupies and how it's distinct from those projects. It's kind of like GraphQL, except instead of the network boundary, it's like the component to data store boundary on your client app, which it, that's useful . [00:28:11]

Like what you just said about how you don't normalize in RTK query, I've landed on that as being generally a good architectural decision to make in applications because like if you start doing data transformations, you know, bespoke data transformations per endpoint, then it becomes really hard to change those endpoints. [00:28:33]

If you're changing the underlying data, then you've gotta change all the code at the same time. Whereas if you just take whatever the API gives you and then write like a transformer on top of that, then it's just you, you add a layer of abstraction for yourself that gives you a little bit more flexibility around timing of some types of changes. [00:28:53]

So, yeah, I don't know. That's, it's interesting. This is an interesting project. I dunno, something about it feels like I don't quite know where I would take advantage of it for myself, but I could see the right app with the right kind of team operating it, finding this and being like, this is exactly what we need. This solves multiple challenging thorny problems that we have or, so yeah, I don't know. It's interesting. [00:29:17]

1-acemarke: My own personal to-do list is massive at this point. Both like Redux and even just like personal life stuff. But I, I absolutely want to go back and, and play with my own RTK query integration prototype for that in the near future. [00:29:40]

2-vcarl: Yeah, I generally love the idea of sync engines. One of my core beliefs about writing code is that many more applications that we use have no technical necessity to be online only. [00:29:52]

Like, there are a lot of things, like, for example, my favorite canonical example of this is like Gmail. If you're using the Gmail app. It doesn't actually care if you're online because it is doing synchronization of your emails in the background. And so you can just interact with it normally while you're fully offline and later it will do all the things like synchronize the read states or like, you know, which emails you've archived and deleted and yada, yada yada. Completely transparently. Like I have never thought about, oh, I should wait to do this later when I'm online so I don't cause weird problems for myself. And I do think about that all the fucking time in various other apps that I use. So like there, that's something that we used to do that we no longer do because it's hard. [00:30:06]

I love seeing more effort and energy being expended into making it easier to do offline things. And sync engines are a big part of that. And so abstractions, over sync engines are also a part of that. Great. [00:30:45]

Tanner teasing a WIP TanStack Start RSC implementation

1-acemarke: The Tan Stack router folks also put out a really good blog post talking about how they did some massive optimization on route matching, including using a somewhat lesser known data structure called, I think it's pronounced a try, T R I E. [00:31:01]

I love I I love seeing optimization breakdowns. So good article there. And then since we've done plenty of, you know, stuff being teased on Twitter discussion in the past with Remix and everything else, Tanner has been teasing that they are working on RSC support for Tan Techstar. And I can say that he showed me a demo and it's unconventional. [00:31:13]

It is not what you would expect after having used Next, and yet it totally makes sense in its own way once you see it. So as I understand it, they've made real progress on implementing it. They've figured out the design and now it's push it forward and make it actually a thing. I have no idea how soon this will be revealed, but I think once this comes out, it will be a very interesting, challenging take on our understanding of server components and how they, how to use them. [00:31:36]

2-vcarl: I would certainly say that the way Next has done it does not seem to be like the end all, be all of great implementation. So if they have found a new way to approach it, hell yeah here for it. That's awesome. [00:32:10]

1-acemarke: So there, there's your vague tweet for the month. [00:32:21]

2-vcarl: Yeah. Right. [00:32:24]

State of the web ecosystem

2-vcarl: Let's talk a little more broadly. Let's talk about the state of the web ecosystem, I guess like to intro our subtopics under state of the web ecosystem. I wanna talk a bit about like the CloudFlare outage, the NPM ongoing attacks. Like this is not a new attack, this is a continuation of the previous attacks, plural, that we've discussed, as well as Alex Russell had a decent blog post. I say decent because I don't know, it's it qualified, decent it, it's well written, it's well argued, but I don't necessarily agree with his conclusions. And also there, there's some conversation about reacts place in the ecosystem and AI and things like that. So that's the shape of this state of the web ecosystem chat that I want to start or that I want to have, I guess. [00:32:25]

Cloudflare November outage postmortem

2-vcarl: Yeah let's start at CloudFlare. They had an outage on the, earlier this month, about a week ago, 18th of November. They say in their outage postmortem that it was triggered by a change to the permission system of one of the databases, which caused it to output entries ba- basically, it produced too large of a file that then got distributed out and the size of that larger file getting distributed caused performance load that took down the network. [00:33:13]

1-acemarke: Check me this. Another factor on it was they, one of the services was written in rust and it had an expectation that the file would only be so big and there was, I think there was a rust line of code that basically said if it doesn't fit, panic. Yeah. That a bad file with like they had 60 features, a limit of 200 and a line of code that basically said if it gets over 200, throw, throw an error or kill the service. [00:33:40]

2-vcarl: Yeah, that'll do it. Yeah. "Each module ran on the proxy service has a number of limits to avoid unbounded memory consumption." Somewhat questioned the wisdom of that because the reason you would have limits on memory consumption in place would be to avoid outage and downtime. And so if your resolution to, the outcome of your limit, if memory usage gets too high is to crash, that is functionally very similar to an out of memory error. [00:34:08]

Maybe it's, I guess it's easier to debug, I guess you can, out of memory errors cause crazy, unpredictable failures, I guess. So at least this is a predictable failure that strongly indicates where the, the excessive memory use is coming from. [00:34:36]

But yeah, it, it was pretty serious. I actually didn't notice, which I'm glad about. It's nice to not be so online that you don't immediately notice every, I don't know, every outage, but yeah. This kind of, I think this was a, a, a good demonstration of the place in the ecosystem that CloudFlare occupies and how many different services truly rely on its stable operations. Yeah. [00:34:49]

1-acemarke: Trying to make the trade-offs between the web is decentralized. Anyone can run their own thing versus, Hey, look, there's benefits to having centralization. Let's all put our GitHub, or let's, let's all put our git repositories on the same service so we can, you know, log in and share them and comment back and forth. [00:35:11]

Let's put all our social media comments on the same service. We can have commentary back and forth. Let's all use this widely spread CDN and DDoS protection service that also has a bunch of really cool backend services. And then when one of those big services goes down, it ends up having, or everybody put everything in AW, AWS East one. [00:35:29]

2-vcarl: Yeah. Right, right. Yeah. Right. Or, [00:35:50]

1-acemarke: or even like we, we put it in AWS East two, but AWS themselves relied on AWS East one, and then it goes down. We keep burning into these big dependencies that end up having massive effects on the internet when they go down. [00:35:52]

2-vcarl: This feels like a good transition point to a link that we had slightly later down. [00:36:06]

"What if people don't want to create things"

2-vcarl: Tom McRight, who is not a name I recognize, put out a blog post called What If People Don't Want to Create Things? And that feels like what you're talking about, like the ideals of the web is decentralized, you know, their own domain, right? Sharing knowledge, sharing skills, sharing tools, and I love that. I agree with that. I aspire to those ideals. [00:36:10]

But it's also true that like we kind of just want stuff to work. We want it to just kind of be stable and you know, what's not stable, decentralized things that have a smattering of volunteers maintaining it. That's kind of the distinction. Like that's kind of the trade off is like over time decentralized things with enthusiastic maintainers and open source, over time that stabilizes and grows and becomes great in a way that proprietary code can't, because you know, you can't inspect it, you can't say like, I'm encountering this bug. Let me go look at the code. Oh, here's where it's coming from. Let me tell them about it and give them a reproduction. And contribute to a fix. Like if I encounter a problem like that in any of these many proprietary tools that I use, then there's just no path for me to do that, so. [00:36:33]

But on the other hand, they have the capital and the employees to have people proactively looking for that, where it's their job. That's the tension. I tend to believe over a long enough time scale that distributed, decentralized things like the web will be better than anything that's like proprietarily developed. [00:37:25]

But it has to work well enough to get the attention. And you know, in this attention economy we're in, it's very hard to get people who have enough bandwidth of their attention to say, "I have found this problem, let me chase it down to its logical conclusion and contribute to a fix being actually shipped for me and people like me." [00:37:47]

1-acemarke: We aren't gonna go off on this, but I can even see some tangential connections with things like open source as a concept, open source maintainer, burnout. Like most people like using an app or a library or even even developers using a library, like in the end, do they actually care that it's open source? [00:38:05]

No, they just want to download the thing and have it work, whether it's Libre office or you know, a paint, you know, paint program or Better Auth or whatever. And the fact that the code's open doesn't matter. It's like I, as the consumer of this thing at this level, just want it to work. And if it doesn't, I ask the person who builds it, just make it work. [00:38:23]

2-vcarl: Right. I'll call out a couple of quotes from here. "Beautiful data visualizations are free to make, but the supply of people who really love and know D3 is a lot lower than I expected it would be. I love home-cooked apps and malleable software, but I have a gnawing feeling that I'm in a bubble when I think about them. Most people's lives are split into the things that they affect and create and the things that already exist and wanna tune out and automate." [00:38:46]

I think that's a, I think that's insightful. I think that speaks to a deep, I don't know, tension in this. Like, yes, AI lets you do a much larger range in a much shorter time span than used to be feasible. But do people want to do that? I don't know. [00:39:07]

Given the, given a range of infinite possibilities, how do you pick which one that you are going to do and then give it the attention so that it actually produces something that other people can benefit from. How do you find the things that you want to build on top of, you know? [00:39:24]

“When Everyone’s a Developer, How Do We Promote the Web Platform Over React?”

2-vcarl: Well, I guess I'll transition from that, from that comment to this other post. "When everyone's a developer, how do we promote the web platform over react?" It's in reference to this Alex Russell Post that I'll, I'll, I'll share after. But I guess it's talking about, it's talking about that like when people can make their own software, when they can just use plain English to ask AI to generate code that in one form or another, solves the problem. [00:39:39]

They stated, you know, maybe not the way they intended, maybe not the way they wanted, but it. It's doing its best, just like all of us. It's talking about how if you just ask it to make something, it's probably gonna use React, because that's what, by volume of text, by volume of code that it's trained on. That's what, that's the mode. That's the most common example. [00:40:03]

I guess, like this is framed as a, an AI problem, like why does AI do this? But this is actually the same problem that I've observed well before AI came out, you know, 2022 or when everyone chat GPT really started, I have observed all of these problems that it's talking about over the life of my career. [00:40:20]

Like, you know, especially I feel like, you know, there's a certain golden age of tech between 2018 and, I dunno, 2021 or so, and that was absolutely the case. Like I would, you know, join a new workplace, because I did that a lot, I worked at a lot of different companies and I'd look at the practices people were using. It's like, why did you use React for this? Like there's, here's a platform feature that solves this more easily. And with less code. And a lot of the time people just didn't know it existed. Like it's that attention problem. How do you know what you should build on top of? [00:40:38]

I don't know. It's the solutions here that people are talking about is like, what can we, the web community do to promote web platform features over react code and it proposes teach vibe coders to explicitly prompt for web native solutions, get the LLMs to ingest more web platform code, spotlight teams and projects that ship modern web experiences without heavy frameworks. [00:41:11]

I mean, like that's, to me, all of those essentially just like how do you make the web platform more popular? To me, ai, it fundamentally spits out an average. It spits out like, you ask it to do something and it will give you a deeply profoundly average result for, you know, if you asked a thousand people, that question here is approximately what the mass of those people would say. And it's true that if you asked a thousand developers to do something on the web, the most common output would probably be a kind of shitty implementation with React that overused things like use state news effect because that's what developers did and do. So I don't know, it's like a lot of these questions that we ask ourselves about AI and code, I feel like distill down to the same kinds of questions we were asking before. [00:41:33]

But like now there's a boogeyman of ai, like this is ai, this is this, this is code, this is a product people have built. And so it is now a very convenient boogeyman, but it, it's a distillation of the thoughts of a vast number of people as codified by what they published and what was ingested for the training set. [00:42:26]

1-acemarke: I just tossed in a link to the obligatory XKCD from like a decade ago, which is the, the one of the points out that sometimes your, your map or your heat map of users is actually just a heat map of the population. It's a one-to-one correspondence. And so I think that that is partly what we see with like React usage. [00:42:46]

You know, there, there's a lot of people. Who use React. There's a lot of people who use React badly and therefore, like the spread of types of usage of React, the quality of usage of React kind of maps to the quality of programmer skills and backgrounds, like not necessarily an excuse. And that's not to say that like everything about using React is is good by itself, but just that when you have a full cross spectrum of the population using a thing, you're going to have the full cross spectrum of the population using it in good and bad ways. [00:43:07]

And so in the same way when it like, when it comes to, you know, people building apps, re React got popular, when LLMs came out and saw that was re React was popular. So LLMs repeat what they were trained to do, and plus it's also, you know, like not just popular, but it's especially popular within Silicon Valley, within all the companies making the AI builder tools, et cetera. So in a lot of cases, they're prompting them to just use React because they assume it's the default that you would use anyway. [00:43:45]

2-vcarl: I, I wanna shout out a term that I love, "path dependence," which is like, where you're at right now is the outcome of a series of choices that were made in the past, and those past choices constrain what paths are available moving forward. That's path dependence. Where you came from affects where you can go. [00:44:13]

And so I guess like to me that this is a complaint about the path dependence of React. Like because React got popular now React is, we've worn that rut and so now it's hard to get out of that rut even if there is a better alternative. [00:44:35]

And so I would say like the solution there isn't like, I don't know, tell people they're bad at things. The solution is to like make better resources so that a different path becomes the easiest one to take. En masse, you know, writ large, when, you know, it's one thing to convince 15 people that this is the best solution and it's correct. [00:44:51]

And it's another to make the argument clearly enough, strongly enough, and consistently enough over a long enough span of time that it affects the behavior of millions of people. So, you know, how do we promote the web platform over react, like do a better job promoting the web platform, 'cause there are thousands of people who are writing resources for React because that's where money and attention and time is. [00:45:14]

So if you want to do better than that, you have to make a resource that is better. I don't know that. There you go. [00:45:45]

1-acemarke: Yeah, so the, the, the other, there was a related article from last month entitled Dead Framework Theory, which was specifically addressing like the the LLM training data aspect of this and how it, how it becomes a, sort of a self perpetuating cycle. [00:45:53]

And also pointing out that like if you have a, a new library or a new tool or a new web platform feature that is just now baseline, newly available, there's a lag in common LLMs knowing about that. So it's sort of like that defaults win kind of an issue. [00:46:07]

2-vcarl: Yeah, and I'll say, yes, defaults win, but that doesn't mean that it's impossible for an, you know, to approach the problem in a way to mitigate that kind of, you know, home field advantage that tools like React have. [00:46:25]

I've shout it out a number of times, in a bunch of different contexts, because they do a good job! But I love effect. One of the things they do really well is documentation, and one of the things they do really well in their documentation is making it legible for ai. I recently, over the summer, built a greenfield project with effect, and I did it extensively with ai, a mixture of having it write and then having it educate me and then rewriting it, and then having AI rewrite what I did, you know, just get there over time. [00:46:38]

But I was able to do that despite it being a new library that's even at odds with the kind of patterns that AI wants to write, it's a functional type, it's a functional programming typed standard library essentially, which is not at all what AI wants to write. AI wants to write object oriented classes. And despite that, I was able to make it, figure it out and learn it and do a good job, good enough job that I got something I was proud of. You know, not just vibe coded. I was proud of it. I told people in my life, this is the best code base I've ever worked on. [00:47:07]

And it's a large part of that was because of how the effect as a, you know, organization and library approach, their style of documentation. They made it legible for these automated tools. So I guess like if you wanna promote the web platform over. Incumbents like React then like figure out how people are writing code, figure out how people are consuming documentation, consuming new knowledge and do a good job. [00:47:36]

1-acemarke: I'll note though, that you, you are the one who decided you were going to use effect and told the LLM, this is what I'm going to build. [00:48:03]

2-vcarl: It's true. Yeah. [00:48:11]

Alex Russell’s latest stats on web devices and network budgets

1-acemarke: The last wink on this particular topic, Alex Russell, who used to be at Google now has been, Microsoft has been very vocally beating the drum that most client side JS is bad, that JS bundles keep growing, that most people are using. You know, older Android devices on mobile with very weak CPUs and therefore JS load times are worse versus, you know, developers using an iPhone or, or a Power or a Fast Mac or something. [00:48:12]

And he just put up the latest article in his ongoing series. You know, documenting, stan-, like average bundle sizes, average network speeds, average CPU uses. I have a lot of respect for him. Technically, his stats are correct. His points are right. I have questions about his delivery and tone in how he accuses people of doing the wrong thing. But it's also very true that a lot of the people should be paying more attention to him and actually trying to shrink down bundles instead. [00:48:41]

2-vcarl: That's interesting. I, a thought I've had, I haven't validated this thought against, you know, ground truth, but I've been hearing about bundle size as a problem. Essentially what he's talking about here, like we ship too much JavaScript for the compute capabilities of commonly used devices, like that as a thesis has been something I've been hearing about for a very long time, much of my career even, and I'm not sure that the bundle size problem has gotten that much worse over the last, I'll say eight years, you know, call it since 2017. [00:49:14]

And he shows a chart of compute speeds and basically shows like, yes, top of the line devices have gotten five times faster, low end devices that 75% of the world uses have not gotten measurably faster. And that's true. Can't argue it. His stats are correct, like he said, but also like I'm not sure the problem is getting measurably worse. [00:49:52]

The optimizations of how we can split code and you know, what the JIT and the execution environment is doing to make it work more quickly. Those have gotten better over time. And it's also true that like, so if he's looking at the, basically like every processor, anyone with a device is using and that is the correct stat to consult if you are building something that everyone in the world will access. [00:50:14]

But that's not true for most startups. Like if you're building a startup that targets like some industry, that American businesses, is, targets a problem that American businesses need solved, then like it doesn't really matter what the mo-, mobile performance in, you know, different outside of that target industry, I guess are then it's like, like what you said about his like tone and delivery. [00:50:45]

I think a, to me when I read this, a core part of what, that I think he's overlooking is that not everyone is trying to ship something that 100% of the people in the world can access smoothly and quickly. Like, and that's fine. Like, you know, not everything needs to target everybody in the world. So, I don't know, I, I guess that that's one of my takeaways. [00:51:09]

That's one thing that I think is missing from this, otherwise very technically complete blog post. [00:51:30]

1-acemarke: I think it's also true that an awful lot of app teams out there ought to be spending time thinking about like even just basic bundle sized stuff and they aren't. [00:51:37]

Npm attack, Shai-Hulud round 2

2-vcarl: I do wanna talk about the NPM hack that is ongoing Shai-Hulud, the sand worm. [00:51:48]

I want to call out. As far as I know, aikido.dev has been like the security researchers who have announced this, like uncovered it and then analyzed it and shared it. [00:51:55]

Analysis of its evolution in code from Sept

2-vcarl: They had a really good analysis of the evolution of the code, of the attack of this worm from September, and I noted in that when I was rereading it after this, you know, new, new attack, they had shouted out that it appeared that they still had more credentials in reserve. Like they had cracked more credentials than they had actually used. [00:52:06]

And sure enough, this, you know, round two attack in their analysis of of it this time around, they note that it was timed just before NPM's deadline for revoking old tokens. So like very clearly they had a lot of tokens that they had compromised previously that they were now taking advantage of before they, before they lost access to it, before those tokens were no longer valid. [00:52:29]

And I guess to reiterate, we've talked about, we talked about this attack before, I would say this is, this represents the current cutting edge of malware. It is using all sorts of fascinating root execution, like privilege escalation. I saw discussion of it, starting a docker container, mounting your file system to that privileged environment and now suddenly it has privileged access to all sorts of files that it couldn't have if it was just running in your shell. [00:52:48]

There's stuff like that that's pretty fascinating and other things like if you have a Claude installed, it will prompt Claude to say, "Hey, look around this file system for secrets." like that is very cutting edge malware. To me, it's, it's not just writing its own code. It's not just a worm that is trolling your file system. [00:53:14]

It is taking advantage of other tools that you take advantage of to attack you. So it's, yeah. That's not great. [00:53:32]

1-acemarke: I mean, like, big picture, it's almost, it's almost surprising how many widespread pieces of malware have been very dumb and weren't as nearly destructive or smart as they could have been. And like think of how much damage we've had collectively as an industry over years with only a lot of those dumb malware. [00:53:39]

And now we're starting to see some people write more intelligent malware. [00:54:01]

2-vcarl: Yep. Yeah. 'cause a month ago, or two months ago, whenever it was, there was a different NPM hack that managed to get into the debug package, which is massively widely used. And I assumed that it was the same attackers as this attack because it's, it, it resembled it in a couple of ways, except that it was dumb. It was so poorly executed. [00:54:05]

Like they got close to unprecedented access to the NPM ecosystem like. This is one of the first times that that previous attack, the debug attack, was one of the first times that I saw, "here's this compromised version. Let me check my file system. Oh, yep, there it is. I've got this." [00:54:26]

So yeah, they just straight up fumbled the bag there. My theory here, having paid attention to this, it seems like there's some hacker group that may have compromised, set up a phishing tool set, you know, set up tools for other malicious actors to run phishing attacks. And it feels like two different hacker groups took advantage of those tools to target NPM maintainers. [00:54:45]

And only one of them is actually technically competent enough to take full advantage of the access that they got. So yeah, I believe we've shared these resources before. [00:55:13]

Our plan for a more secure npm supply chain from September

2-vcarl: And GitHub put out our plan for a more secure NPM supply chain, so they're still working on that clearly. [00:55:23]

NPM update on token management changes

2-vcarl: They also just released an NPM security update earlier this month in November, November 5th. [00:55:29]

⚡ Lightning round ⚡

2-vcarl: Mark, you want to just read through any of these lightning rounds that you wanna call attention to? Okay. [00:55:34]

TS 6.0 hopefully Feb 2026, 7.0 (native) soon after (more details in the TypeScript.fm podcast)

1-acemarke: TS six and TS seven are hopefully gonna be coming out early next year. TS six is still the current TypeScript code base, but with some changes to defaults and deprecation. And then TS seven would be the native implementation in go that they're working on. [00:55:38]

So a couple different updates on the release plans there. That's going to be very, very exciting. I am excited to have TypeScript compiler 10 times faster. [00:55:54]

Latest TC39 proposal updates

1-acemarke: Also there were some more. The latest TC 39 proposals meeting as usual, advanced a number of different proposals to different stages. A couple of things that look interesting. [00:56:03]

There's a promise do all keyed, which is essentially promise dot all but for an object. And then I am excited, un irrationally excited about object keys length, which is literally just to get the size of the number of keys in an object instead of object keys, parentheses, length. [00:56:13]

Chrome (and other browsers) wants to remove XSLT from the web platform

2-vcarl: Chrome, and a couple of other browsers want to remove XSLT from the web platform. XSLT is a, what, domain specific library for transforming XML? [00:56:32]

1-acemarke: XML transformations within a browser. So you, you send out an XML document from the server, and then you have a purely client side declarative transformation that like converts it into HTML. [00:56:42]

2-vcarl: It exists. I had no idea that it was a browser feature. I've known of it as a tool that exists, but I had no idea it was baked into the browser and they're looking to remove it and I'm okay with that. But certain people who I guess use it for one thing or another have been running a campaign to say, "no, please don't. What about RSS feeds?" But yeah. [00:56:54]

“Your URL is Your State”, and David K’s “Goodbye, useState” talk

1-acemarke: Going along a bit with the whole use the platform thing, more people should be putting some of their state in the URL and there was a very good article on using the URL as state. And then along with that, another video from recent React Summit that's probably paywall at the moment, but I think he's done a couple previous versions of this at different conferences. [00:57:14]

David Kourshid has a talk on goodbye used state, similar to his goodbye use effect. It's hilarious, it's funny, and it also points out why you shouldn't be using actual used state all that much. [00:57:33]

Aiden Bai’s “React Grab” util

2-vcarl: Aiden Bai, who did millions js put out an interesting new tool called React Grab, basically letting you, you know, you, is trying to solve the problem of when you tell AI like, "Hey, make this thing different." And then it goes, "I don't know where that is. Here's your browser, but I don't know where that is in the code base." [00:57:46]

And so this is a tool that helps map similar to how you can use dev tools to highlight an element. This is taking that kind of behavior where you highlight an element in your browser and it connects back to the actual source code that produced that element as a means of giving AI a head start on finding what code to use, which seems super cool. [00:58:03]

I questioned the wisdom of the recommended get started thing, which is just to add a script tag to unpkg. I don't know. Seems, seems slightly sketch, but also for also seems really easy to, to get started. [00:58:25]

Creating a custom Node module loader to import from Bittorrent

1-acemarke: One thing that caught my eye in terms of like, this is awesome and you should never, ever do this, was implementing a node module loader that imports from BitTorrent. [00:58:39]

Okay, great. That's possible apparently. [00:58:48]

2-vcarl: Love that. I do love BitTorrent. You know, as we were talking about decentralized technology a little bit earlier, like, man, what a highly resilient, decentralized technology. But yeah, well, hey, you know, maybe if we're gonna tell you, if we're gonna encourage people to do decentralized technology building on the shoulders of giants, like it, man, if you want it to like never stop working, ever, sure, import your code from BitTorrent, probably it's not gonna work very quickly, but given the right underlying seeders that would, that may never go down. Pretty interesting. [00:58:52]

Ryan Carniato’s stream on researching “async signals”

1-acemarke: Earlier I mentioned Ryan Carniato streaming and talking about async signals. Here's the six hour livestream video if you want to watch that and or throw it into a summarizer somewhere. [00:59:22]

Details of building Node’s TS type stripping support

2-vcarl: I'll shout out the details of building nodes, the node type, script type stripping support, just 'cause I, man, I do love a technical writeup and that is, that was a massive feature release, just like the ability to use node to run TypeScript code without doing a compilation step. Was pretty cool. And so here to here to signal boost a post from the author of it. [00:59:33]

The Web Animation Performance Tier List

1-acemarke: And one more, since we spent much time talking about the, the web platform, the author of the motion animation framework put up a really good post comparing all the different ways you can do animations on the web and talking about some of the performance trade offs. [00:59:58]

2-vcarl: Super good. Cool. [01:00:12]

Conferences (React, Javascript)

2-vcarl: Into some conference news. [01:00:14]

We don't really have much 'cause it's the end of the year and all of the upcoming conference things don't show anything for like January or February. [01:00:15]

CFPs

1-acemarke: Well, we don't have much of a list here, but I can say that I've actually been doing my own, trying to prepare CFPs for next year and it ended up making a database of conferences and like my own personal list is like dozens of them. [01:00:22]

And I can tell you there several conferences have submission deadlines like by November 30th s Why? I'd say there's a lot more conferences out there that knew existed until I spent several evenings spent researching them and trying to put this database together. [01:00:35]

2-vcarl: I've tried to do that consistently over the past three years for this podcast and holy shit, there are so many conferences. It is absolutely bananas. Some of them are even fraudulent, so it's like you, you actually gotta them. So yeah, it's a lot. But okay. [01:00:47]

React Paris (Also a community survey)

2-vcarl: All that to say, I am aware of, React paris has a CFP currently open, but that's gonna be in March. So if you're looking to talk, then they've got a CFP open, you can do that. [01:01:01]

JSWorld CFP closes Dec 31, notifies by Feb 1

2-vcarl: JS World also likewise has a CFP that closes at the end of December. [01:01:12]

Ending

2-vcarl: Thank you everyone who has managed to stick around for this, you know, hour and 15 minute recording session. [01:01:18]

1-acemarke: Funny we said we didn't have a lot of main content for today and go figure. We had a lot to say about stuff. [01:01:24]

2-vcarl: Yeah, right. I give us a, give us a blank slate and we will fill it. Boy howdy. [01:01:29]

1-acemarke: Hopefully the discussion has been useful. [01:01:34]

2-vcarl: That is my hope. I, if not useful at least. Interesting. Cool. Thank you for joining us. We normally, I say we'll be back on the last Wednesday of the month, but the last Wednesday of next month I think is [01:01:36]

1-acemarke: December 31st, [01:01:48]

2-vcarl: so I don't know, we're probably not gonna do it on the last Wednesday of next month, but we'll be back [01:01:49]

1-acemarke: somewhere about that timeframe approximately ish. [01:01:54]

2-vcarl: Before the end of this year. [01:01:57]

Yeah. Generally, I say we gather sources from all sorts of news feeds and whatever, but Mark, you've done a good job of being my source lately. So mostly we get news from #tech-news-and-reads, or at least that's where I get it. [01:01:59]

I don't know where Mark gets it. [01:02:11]

1-acemarke: All of the above newsletters plus like Hacker News and Twitter and all the other social media feeds I obsess over. [01:02:13]

2-vcarl: But yeah, we do subscribe to this week in React by Dev React status next year. It's weekly. Mark and I are both subreddit mods of React js. But yeah, if you see anything that seems useful that you might want us to discuss, drop it in the #tech-news-and-reads channel. [01:02:20]

I'll at least read it. I may not bring it in, but yeah, if this is a show that you get value from and wanna support, the best way to do so is by telling people about it and submitting a review that'll help us get discovered and whatever. [01:02:36]

Cheers. Thanks so much. [01:02:48]

1-acemarke: Happy Thanksgiving. [01:02:50]