diff --git a/src/transcripts/tmir-2025-12.md b/src/transcripts/tmir-2025-12.md
new file mode 100644
index 0000000..c523838
--- /dev/null
+++ b/src/transcripts/tmir-2025-12.md
@@ -0,0 +1,1022 @@
+---
+title: "TMiR 2025-12: Year in review, React2Shell (RCE, DOS, SCE, oh my)"
+date: 2025-12-18
+time: 10am PT / 5PM GMT
+location: Main Stage on Reactiflux
+description: "Join Carl, Mark, and Mo as we take a look at what happened This Month in React. We'll break down what's new in an hour-long conversation."
+people: "[Carl](https://bsky.app/profile/vcarl.com), [Mark](https://bsky.app/profile/acemarke.dev), and [Mo](https://bsky.app/profile/mojavad.bsky.social)"
+---
+
+
+
+
+
+- [[00:00](#introduction)] Introduction
+- [[07:25](#main-content)] Main Content
+ - [[07:32](#react2shell-vulnerability)] [React2Shell vulnerability](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)
+ - [[15:31](#initial-announcement)] [Initial announcement](https://www.cve.org/CVERecord?id=CVE-2025-55182)
+ - [[16:12](#followup-denial-of-service-cve-and-source-code-exposure-cve)] [Followup denial-of-service CVE and source code exposure CVE](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components)
+ - [[19:05](#vercel-bulletin)] [Vercel bulletin](https://vercel.com/kb/bulletin/react2shell)
+ - [[19:32](#cloudflare-report-on-exploit-attempts)] Cloudflare
+ - [[19:32](#cloudflare-report-on-exploit-attempts)] [Cloudflare report on exploit attempts](https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/)
+ - [[19:39](#cloudflare-outage-on-december-5-2025)] [Cloudflare outage on December 5, 2025](https://blog.cloudflare.com/5-december-2025-outage/)
+ - [[20:58](#tech-analysis-flight-protocol)] Tech analysis: “Flight Protocol”
+ - [[22:33](#vuln-is-carefully-crafted-promise-deserialization--new-function-eval)] Vuln is carefully crafted Promise deserialization + `new Function` eval
+ - [[23:14](#prs-initial-fixes-promise-cycles--function-tostring-more-promise-cycles)] PRs: [Initial fixes](https://github.com/facebook/react/pull/35277), [Promise cycles / function toString](https://github.com/facebook/react/pull/35345), [more Promise cycles](https://github.com/facebook/react/pull/35351)
+ - [[24:09](#guillermos-breakdown)] [Guillermo’s breakdown](https://x.com/rauchg/status/1997362942929440937)
+ - [[24:18](#shrutis-breakdown)] [Shruti’s breakdown](https://blog.logrocket.com/react2shell-exploit/)
+ - [[26:14](#comms-critique)] Comms critique
+ - [[34:59](#react-is-rainbow-colored-function-types)] [“React is rainbow colored (function types)”](https://bsky.app/profile/sh03.dev/post/3m7tz3zhl522f)
+ - [[35:39](#what-does-this-mean-for-react-and-rsc-adoption-going-forward)] What does this mean for React and RSC adoption going forward?
+ - [[44:30](#when-i-go-back-and-look-at-reactdev-now--it-feels-half-finished)] [When I go back and look at react.dev now […] it feels half-finished](https://bsky.app/profile/nearestnabors.com/post/3maa3cof5mh2w)
+ - [[49:14](#react-native-year-in-review)] React Native year in review
+ - [[49:54](#more-css-support)] [More CSS support](https://reactnative.dev/blog/2025/01/21/version-0.77)
+ - [[50:45](#expo-eas-hosting)] [Expo EAS hosting](https://expo.dev/blog/expo-announces-eas-hosting-service)
+ - [[51:18](#rn-078-react-19-support)] RN 0.78: [React 19 support](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
+ - [[52:18](#lynx-launched)] [Lynx launched](https://lynxjs.org/)
+ - [[52:52](#rn-079-jsc-moving-to-community-package)] RN 0.79: [JSC moving to Community Package](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
+ - [[53:27](#rn-080-freezing-the-legacy-architecture)] RN 0.80: [Freezing the legacy architecture](https://reactnative.dev/blog/2025/06/12/react-native-0.80)
+ - [[54:05](#rn-081-android-16-support-for-edge-to-edge)] RN 0.81: [Android 16 support for edge to edge](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
+ - [[54:36](#10-on-the-horizon)] [1.0 on the horizon](https://www.youtube.com/watch?v=GPtopk4y2LI)
+ - [[55:35](#vega-os-launched)] [Vega OS launched](https://developer.amazon.com/apps-and-games/vega)
+ - [[56:22](#rn-082-only-new-architecture)] RN 0.82: [Only new architecture](https://reactnative.dev/blog/2025/10/08/react-native-0.82)
+ - [[56:50](#expo-app-awards)] [Expo App Awards](https://expo.dev/blog/2025-expo-app-awards)
+ - [[57:39](#rn-083-new-devtools---no-breaking-changes)] RN 0.83: [New Devtools - no breaking changes](https://reactnative.dev/blog/2025/12/10/react-native-0.83)
+ - [[01:00:27](#react-year-in-review)] React year in review
+ - [[01:00:32](#cra-deprecation-new-install-docs-vite)] [CRA deprecation](https://github.com/reactjs/react.dev/pull/7495), [new install docs](https://react.dev/learn/build-a-react-app-from-scratch) (Vite!)
+ - [[01:01:35](#styled-components-deprecated)] [Styled Components Deprecated](https://opencollective.com/styled-components/updates/thank-you)
+ - [[01:01:59](#releases-192-activity-useeffectevent-compiler-10)] Releases: [19.2](https://github.com/facebook/react/releases/tag/v19.2.0) (Activity, useEffectEvent), [Compiler 1.0](https://react.dev/blog/2025/10/07/react-compiler-1)
+ - [[01:02:39](#research-view-transitions-canary-perf-concurrent-stores-throw-a-promise-deprecated-but-not-merged-yet)] Research: [View Transitions canary, perf, concurrent stores](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#view-transitions), [“throw a promise” deprecated](https://github.com/facebook/react/pull/34032) (but not merged yet)
+ - [[01:03:00](#async-react-and-the-ecosystem)] “[Async React](https://github.com/reactwg/async-react)” and the ecosystem
+ - [[01:03:41](#react-foundation)] [React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation)
+ - [[01:04:53](#react-growth-skyrockets)] [React growth skyrockets](https://bsky.app/profile/sebastienlorber.com/post/3mabj2vg23c2l)
+ - [[01:06:05](#react-router-rsc-support-tanstack-start-wip-rsc-waku)] [React Router RSC support](https://remix.run/blog/rsc-preview), [TanStack Start WIP RSC](https://x.com/tannerlinsley/status/1983999424486633931), [Waku](https://waku.gg/)
+ - [[01:06:37](#dans-rsc-explainers-he-had-a-bunch-of-things-to-say)] Dan’s RSC explainers (he [had](https://overreacted.io/jsx-over-the-wire/) [a](https://overreacted.io/impossible-components/) [bunch](https://overreacted.io/what-does-use-client-do/) [of](https://overreacted.io/one-roundtrip-per-navigation/) [things](https://overreacted.io/progressive-json/) to say)
+ - [[01:07:07](#remix-v3-not-react-but-relevant)] [Remix v3](https://remix.run/blog/remix-jam-2025-recap) (not React but relevant)
+ - [[01:08:08](#mark-went-from-frustrated-cra-to-excited-reactconf-foundation-team-efforts)] Mark went from frustrated ([CRA](https://blog.isquaredsoftware.com/2025/06/react-community-2025/)) to excited (ReactConf, foundation, team efforts
+- [[01:12:19](#-lightning-round-)] ⚡ Lightning round ⚡
+ - [[01:12:24](#ts-7-progress-update)] [TS 7 progress update](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/)
+ - [[01:13:17](#npm-classic-tokens-revoked)] [NPM classic tokens revoked](https://github.blog/changelog/2025-12-09-npm-classic-tokens-revoked-session-based-auth-and-cli-token-management-now-available/)
+ - [[01:16:06](#github-actions-planned-work)] [GitHub Actions planned work](https://x.com/jaredpalmer/status/1998821983904243918)
+ - [[01:17:44](#github-action-pricing-change-and-immediate-about-face)] [Github Action pricing change](https://resources.github.com/actions/2026-pricing-changes-for-github-actions/) and [immediate about-face](https://x.com/jaredpalmer/status/2001373329811181846)
+ - [[01:19:40](#stacked-diffs-proposal-in-the-works)] Stacked diffs [proposal in the works](https://x.com/jaredpalmer/status/1999525369725215106)?
+ - [[01:22:42](#anthropic-bought-bun)] [Anthropic bought Bun](https://bun.com/blog/bun-joins-anthropic)
+ - [[01:24:52](#svg-clickjacking-svg-filters-as-logic-gates)] [SVG Clickjacking](https://lyra.horse/blog/2025/12/svg-clickjacking/) (SVG filters as logic gates??)
+ - [[01:28:16](#dan-abramovs-rsc-explorer-accompanying-blogpost)] Dan Abramov’s [RSC Explorer](https://rscexplorer.dev/), [accompanying blogpost](https://overreacted.io/introducing-rsc-explorer/)
+ - [[01:28:36](#instant-loading-github-repo-explorer-using-rscs-without-the-blue-bar)] Instant-loading Github repo explorer using RSCs: [Without the blue bar](https://wtbb.vercel.app/)
+ - [[01:29:10](#react-routers-take-on-rscs)] [React Router’s Take on RSCs](https://www.epicreact.dev/react-routers-take-on-react-server-components-4bj7q)
+ - [[01:29:19](#how-ai-coding-agents-hid-a-timebomb-in-our-app)] [How AI Coding Agents hid a Timebomb in Our App](https://acusti.ca/blog/2025/12/09/how-ai-coding-agents-hid-a-timebomb-in-our-app/)
+ - [[01:30:58](#react-compilers-silent-failures-and-how-to-fix-them)] [React Compiler’s Silent Failures (And How to Fix Them)](https://acusti.ca/blog/2025/12/16/react-compiler-silent-failures-and-how-to-fix-them/)
+ - [[01:31:36](#great-history-of-web-dev-30-years-of-br-tags)] Great history of web dev: [30 Years of
Tags](https://www.artmann.co/articles/30-years-of-br-tags)
+ - [[01:32:17](#nadia-makarevichs-latest-deep-dive-bundle-size-investigation)] Nadia Makarevich’s latest deep dive: [Bundle Size Investigation](https://www.developerway.com/posts/bundle-size-investigation)
+ - [[01:33:35](#extensive-es2026-feature-preview)] [Extensive ES2026 feature preview](https://thenewstack.io/es2026-solves-javascript-headaches-with-dates-math-and-modules/)
+ - [[01:34:53](#react-reconciler-for-blender-3d)] [React reconciler for Blender 3D](https://romanliutikov.com/blog/driving-3d-scenes-in-blender-with-react)
+ - [[01:35:31](#the-why-of-react-fiber)] [The “why” of React Fiber](https://x.com/infinterenders/status/1997359890021634509)
+ - [[01:37:21](#async-react-articles-from-aurora-scharff-and-jack-herrington)] Async React articles from [Aurora Scharff](https://blog.logrocket.com/the-next-era-of-react/) and [Jack Herrington](https://blog.logrocket.com/react-19-2-the-async-shift/)
+
+## Introduction
+
+**Carl:** Hello everyone. Thank you for joining us for this edition of this year in React, since it's the December edition of this month in React, as we're gonna recap what's going on with React, React Native and the web more generally, or I guess really what has happened, what has been going on through 2025, just to give you a little rich perspective. [00:00]
+
+Although we do have so much new stuff to talk about this month, so that's gonna be a little bit goofy too. We gotta balance both. We're actually planning on doing a longer episode than usual this month, mark and I are gonna hang out for closer to 90 minutes. Mo's got to leave at an hour. [00:17]
+
+But yeah. Let's get into it. I'm Carl, I'm a staff product developer and freelance community leader here at Reactiflux, or I run community programs like this and build tools like a moderation bot that is growing steadily more complicated. [00:30]
+
+**Mark:** Hi, I'm Mark. My day job is working at Replay. My second unpaid job is working on Redux related things. And my third unpaid job is copy pasting links like crazy. [00:44]
+
+**Mo:** And my name is Mo. I head the mobile team at Thedo in the uk. And I am a member of the React Native community who organizes meetups, like the React Native London Meetup. And I also organized the RNL Conf, which just happened last month and was great fun. [00:55]
+
+**Carl:** Yeah. A leader in the React Native community. I'd even go so far as to say, [01:10]
+
+**Mo:** I would say member Member is, and member humility is good. [01:14]
+
+**Carl:** yes it is. Okay, fine. A steward. [01:17]
+
+**Mo:** I, I appreciate you, Carl, as always. [01:20]
+
+**Carl:** Let's get into some new releases. Base UI has a v1 release candidate coming on. Yeah. I actually got a chance to speak to the maintainer of Base UI at React Con briefly. I hadn't realized it, but it is like fully a relaunch of, oh, I'm blanking on the other LI library that they were [01:22]
+
+**Mark:** doing. [01:42]
+
+Redx, [01:42]
+
+**Carl:** Yes. [01:43]
+
+**Mark:** or, or, or equivalent of Redx. [01:43]
+
+**Carl:** yes. So apparently Base UI is a relaunch of Radix, essentially because the team got acquired, the RAD X team got acquired. They were given verbal promises that they would be allowed to continue maintaining it as part of their full-time responsibilities. And that was not true and they did not have a contract saying it. [01:46]
+
+So, they have relaunched under a new project, which is unfortunate, but also great. I don't know, sometimes it's nice to get another chance to do the thing from scratch again. I guess. So anyway, they've got a v1 release candidate coming out, which is cool. [02:06]
+
+**Mo:** Next up we have React Native version 0.83, which is very exciting for a few reasons. I'll start from the somewhat non-obvious reason, but it's also a good one worth mentioning, which is there are no breaking changes in this, and I cannot stress how important that is for a React Native version release because, every single time you update a React Native version, it's typically, at least, especially in the past, had a reputation that it is a painful process and you're gonna need to change a lot in your app to make it work. [02:21]
+
+And not having any breaking changes is super cool, like, like big props to the React Native Core team for doing this. And so, super, super cool. And , I'm excited to see this as the direction that we're going with releases, which kind of makes sense when you go back to what we heard at React Conf , and React universe conf other things in this release. [02:49]
+
+The new dev tools , is something that's been in the works for a very long time. And Alex Hunt and some of the other folks at Meta have been working on this for a really long time. We got demos of it earlier. And they've been working more and more on this and adding things like performance tracing and network inspections. [03:07]
+
+So we saw a lot of these as demos earlier, but now it's really, really coming through and uh, we're seeing it in production, which is awesome. So a lot of cool stuff and some other stuff that I won't go into in the interest of time, but massive props to the meta team for getting this out. [03:21]
+
+**Carl:** Yeah. And I believe they gave a pretty big demo of the dev tools at React Conf. Is that right? [03:33]
+
+**Mo:** Yep. But they've also been demoing it from last year at React Universe Con, so it's been, there's been a long time since 2024. They've been demoing this and there's teasers of it coming out at some point. So it's been in the making for a while. Obviously, it's been getting more and more mature and more ready for sort of a production release out to everyone. [03:40]
+
+**Carl:** sure. It wouldn't surprise me if there's some overlap with the new architecture too. 'cause if you're gonna totally change how the internals work, then doing instrumentation and developer tool stuff is really hard. So that makes [03:58]
+
+**Mo:** some tools were really painful before these new dev tools like Flipper, the React Native support got deprecated, was notoriously difficult [04:10]
+
+**Mark:** use. So [04:17]
+
+**Mo:** this is a move in the right direction. Obviously. There was a, there was much demand for it. [04:18]
+
+**Carl:** very cool. [04:22]
+
+**Mark:** Next up the, the last couple months we've mentioned that Christophe Nakazawa had been posting teasers on Twitter for a new data fetching library that he was calling fate. And so he's put out the first alpha of that. The main ideas are, it's got some graph QL like features in terms of components specifying what pieces of data they actually need and being able to sub-select pieces of data. [04:22]
+
+But it's a wrapper layer on top of TRPC, so, it'll be interesting to see how this one actually compares in practice to the 15 million other data fetching libraries out there. But nice to see another new approach. Meanwhile, the void zero folks have several different new and alpha and beta releases coming out. [04:47]
+
+The oxalate linting tool has, and now has support for type aware linting with the Ts go native build built in. And OX format tool has its first alpha they say it is essentially almost entirely prett or compatible I think, maybe not this release, but a future one. They're working to include tailwind formatting support as well, so, faster tools. [05:06]
+
+Very good. Then along with that V eight is in beta and this is the release that will include the roll down rust base build tool replacing ES build and roll up. So they are very, very busy cranking along on all the different pieces of their ecosystem. [05:33]
+
+**Carl:** Yeah. I guess Tan Stack is also exploring and they're, they've released an alpha of an ai, SDK yeah, I don't know. Ai. SDK is so hot right now, or so hot a year ago. This, this is a bit of a late entry into that market. But Tan Stack, Tanner Linsley generally has done so many great things that I'm, oh, you know, I'll see what he do. [05:53]
+
+I'll see what he does here. He's got good opinions about developer experience and the contracts we interact with. Yeah, [06:12]
+
+**Mark:** I, talked to him at, at React summit when he was. Dropping hints that this was in the works, and he said like, it wasn't even something that he was intending to do himself originally, and supposedly a lot of folks from the ecosystem asked if Tan Stack would build an alternative to the Vercel AI SDK, just so there was competition, and that, the main entry here wasn't just owned by Vercel. And trying to take the same vendor agnostic and fully typed approach that all the other Tan Stack tools use. [06:20]
+
+**Mo:** that's so, so important. I'm, and I'm glad someone else is doing that. having the option to have something like Tanex start as a, another way to handle this is just so good for the ecosystem. And I am glad that someone's tackling the AI SDK space because. Yeah, competition's great. [06:54]
+
+**Carl:** Yeah, no, it, it totally agree. I don't know. It's feels very good to have a legitimate community maintained option that's not, like, great Google's doing it, Facebook's doing it, everyone has their own thing, but like, really nice to have one that's open source first, so that's good. [07:10]
+
+## Main Content
+
+**Carl:** Yes. Okay. Let's get into our main content, starting with can anyone guess it's gonna be the React2Shell vulnerability? [07:25]
+
+## [React2Shell vulnerability](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components)
+
+**Carl:** The biggest news in a very long time, What happened? It was a major, major remote code execution vulnerability in RSCs where you didn't even need to be using RSCs for your app to be vulnerable. [07:32]
+
+If the server supported it, then an attacker could send a specific payload to your server and get a remote code execution. It's real bad. This is Like the fact that not only is it full remote code execution, but combined with the fact that you don't even need to be taking advantage of the feature, it just needs to be enabled in your environment is pretty bad. [07:48]
+
+That's pretty bad. Actually, in the ensuing drama. So a uh, longtime, serial entrepreneur in the community was posting about like "uhoh, I think I'm vulnerable. Uhoh. Yep. I got exploited uhoh. My docker is also vulnerable to a recent vulnerability that enabled container escape." So like it turned, just like researching this React vulnerability combined with some other recent container vulnerability they were exposed to let an attacker not only get into their system, but escape the containment of what is supposed to be a security layer there. [08:12]
+
+So, yeah. Oof. it's been a bad six weeks. No, it's been a bad year. It's been a really bad year for computer security. Like, holy shit. [08:46]
+
+**Mark:** How many different problems have we listed like there were, we'll talk about it more later, but Next middleware bypass, NPM Hacks, NX React2Shell, like the JSD ecosystem is hurting. [08:55]
+
+**Mo:** I think we've heard anything quite as bad as this. Like as in the industry since the big job of vulnerability in 22? [09:07]
+
+**Mark:** I, think It I I think that was Log2Shell maybe. [09:14]
+
+**Mo:** was like that was the last [09:17]
+
+big where you heard about it all over where people could exploit Java spring applications. So people were just exploiting backends left, right, and center, and it was a serious critical vulnerability. [09:19]
+
+I think this is like like as bad if not worse, and there hasn't been anything quite the severe since then that I can recall making news like this. [09:28]
+
+**Carl:** Yeah, You get one of these [09:36]
+
+every couple years. 'cause Log2Shell was definitely one of them. I remember Heartbleed 10 years ago. these do happen. It's never good when it's your ecosystem. I don't know. thing I said is, serious vulnerabilities like this, they don't necessarily, they don't really what, what I take away from it or what I recommend people take away from it is not, this tool is insecure. These people maintaining it are idiots. [09:38]
+
+Like, no, this is, security is really fucking hard to get right. It is an adversarial space where, as brilliant as you are, your primary task is not making something impenetrable. Like that is second a secondary goal of anything you're doing as a software developer if you are not a paid full-time security engineer. And doing something useful it is just really hard without introducing vulnerabilities like that. [10:06]
+
+So the line that I like is that CVEs, like a critical CVE doesn't mean that it's insecure. It means that it's worth targeting. 'cause most tech is insecure. Like if unless you have dedicated significant resources towards hardening it, it's insecure, like definitely a hundred percent. [10:32]
+
+So the fact that it took this long for it to get revealed to me says that they have done hardening work, they have put effort into making it secure. And because they put that effort in, the actual vulnerability was complicated enough that it took several years before somebody actually figured it out. [10:52]
+
+And also I'll say, I know that I, I saw a tweet from uh, Malte Ubl, the CTO of Vercel you know, engineering leadership at Vercel saying that in the wake of this they did a bug bounty hackathon and ended up paying like $750,000 in bounties out. Presumably that's a long laundry list of like minor vulnerabilities. [11:12]
+
+I don't, I don't believe they've commented publicly about what exact [11:33]
+
+**Mark:** I, I think, I think that one may have been somewhat related to Elle's application firewall rules that they, that [11:36]
+
+**Carl:** So this is their consumer facing security tool to make it. More protected and they found a whole bunch of new ways to make it safer is what it sounds like. [11:44]
+
+**Mark:** Mm-hmm. [11:52]
+
+**Carl:** Cool. Yeah. Great. Yeah, I guess to say a little bit more about where this vulnerability came from and why it was so serious, like this level of vulnerability is fairly rare and JavaScript, I would say largely because in general , the types of code that have a greater risk of introducing this type of vulnerability, usually you'll just farm it out to a different, something that's already been battle tested and hardened in that way. [11:53]
+
+Specifically why this happened is because, so React is basically a scheduler at this point. It's scheduling work. It is, competing with V8 and other JavaScript run times in order to do scheduling of execution. That's just like, as they were building React and realizing the performance snafus they were running into, like they realized, oh shit, we have to write a scheduler. [12:21]
+
+And that was, do you remember what the code name for that was? Mark? [12:44]
+
+**Mark:** That was fiber. [12:47]
+
+**Carl:** So like that was React Fiber. It was, "we're turning React into a scheduler." Now server components are , basically building on top of that. It's saying, okay, we built a scheduler. Now we've realized that in order to provide the kind of experiences we want to be enabled to offer, we think that we have to transcend the network boundary and be able to schedule work not just on the client but across the client. [12:48]
+
+We need to be able to pause execution on the server, put it in a little box, send it across the network, then open the box and pick up right where we left off on the client. And that's fucking hard. So like they already built their own scheduler, so like that's bespoke. You can't just use existing tools for it because they made it. [13:13]
+
+the reason this vulnerability came in is because as part of pausing execution, bundling it up and shipping it somewhere else, that's serializing it. That is serializing a complex set of execution state. And where else have we talked about serialization being a major ecosystem level? Project, it's the React Native new architecture. So like this is the same problem. Serializing is slow. It's vulnerable because you're taking data and if you wanna make it as compact as possible, you have to invent a binary format. [13:33]
+
+And as soon as you do stuff in binary, that's really dangerous because people can structure payloads so that the binary data lines up in just such a way that a naive interpreter on the other end of it that opens, it goes, oh, I know what this is, runs it, and oops, then you've got like a shell escape or like a terminated memory before or after you just like, that's, how you get all of these most serious vulnerabilities is a binary formatted data source gets deserialized, and somebody tricks that deserializing process into thinking that something different than was actually sent is there. [14:09]
+
+**Mark:** We'll dive a little more into the, technical aspects of this later. But big picture is the, the flaw itself was in the serialization deserialization logic, which was written in order to be able to handle serializing and deserializing And because it was generic code in the sense that it was meant to handle, conceptually any piece of data, carefully crafted input could, when revived , run as promises get turned into a function, constructor escape the sandboxing. [14:46]
+
+And next thing the attacker is running arbitrary JavaScript code within the context of your server. And then very bad things happen. [15:22]
+
+## [Initial announcement](https://www.cve.org/CVERecord?id=CVE-2025-55182)
+
+**Mark:** So the initial announcement came out it was timed with a bunch of fixes from all the different RSE frameworks. So, clearly the, the work had been done behind the scenes for coordinated disclosure and fixes. [15:31]
+
+All the major hosting platforms for CloudFlare, Dino Netlify also immediately came out with application firewall rules to try to block, what they knew about the attack at the time. And as Carl said, once someone knows that there's vulnerabilities in a certain system, everyone else in the penetration security space is gonna swarm and look for other potential issues in thing. [15:45]
+
+## [Followup denial-of-service CVE and source code exposure CVE](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components)
+
+**Mark:** And so that's why the next day there was a second set of announcements saying that two more new CVEs had been discovered. One was a denial of service attack where React would try to infinitely revive a series of fake promises. And then the other one was a source code exposure vulnerability, where crafted input could force the API to return the contents of a server function that you had written on your backend. we had the one truly bad CVE, the remote code execution. And then as other people looked at what was the fix, what was the area, what's going on, what else can we find? A couple of additional follow on things were discovered. And you know, as Carl said, it's, yeah, those were there, but it's also, and now people are looking for them because there's the potential for more problems. [16:12]
+
+**Carl:** If you can do a remote code execution, that probably means you can do other things most likely, very proximal to that same vulnerability because like so much of it relies on manipulating the binary encoding. That , that smells like . If you can do that, you can do other things. So I'm not surprised to find that they found other things. [17:07]
+
+I will say like remote code execution, source code exposure, and denial of service. Like, oh, that's rough. That's like the trifecta of things you don't want to happen. So yeah, finding all of them, it's like now we know that they're not there in that way at least. So like great. To me this builds trust a little bit. I actually chatted briefly with Ricky Hanlon in the wake of this and asked what kind of security hardening they have, what's kind of security review they have done as part of designing this. [17:25]
+
+Because, like I said, like Serializing deserializing is a well-known dangerous place to be. It's a dangerous place to find yourself. Like there are projects that I've not done because I realized like, oh, in order to do this, I'm gonna have to touch binary stuff. And that gets really hairy and you have to do that very delicately. [17:58]
+
+So like that to say like, there are smart people on the React core team. Like they absolutely knew this was a risk. And I'm curious to hear more details about what mitigation they've done over the last, six years that server components have been in development in one form or another. Yeah, so Ricky Hanlon said that he'd do some research on that and include it in the post-mortem blog post, but I, I haven't seen the post-mortem blog post yet, so [18:15]
+
+**Mark:** So , this happened in what, December? 11th ish, I think. [18:41]
+
+**Carl:** Yeah. second pair of vulnerabilities was the 11th. First one was the third. [18:46]
+
+**Mark:** Okay. we had the initial announcement, which was dubbed React2Shell. Vercel has put together a, a very comprehensive set of details on what happened. looks like December 3rd. December 4th was when the initial announcements came out. [18:51]
+
+## [Vercel bulletin](https://vercel.com/kb/bulletin/react2shell)
+
+**Mark:** Vercel's bulletin has a lot of info on the timeline and how to fix things, which is basically upgrade to the latest version of any React based framework. [19:05]
+
+Now, if you haven't already done so. And they provide instructions on how to do that. In the wake of all this, we've already seen the vulnerabilities being exploited. Carl mentioned a Reactiflux community member who got hacked as a result. [19:15]
+
+## [Cloudflare report on exploit attempts](https://blog.cloudflare.com/react2shell-rsc-vulnerabilities-exploitation-threat-brief/)
+
+**Mark:** CloudFlare put out a post detailing. "Yeah. We're, seeing this getting used in a lot of penetration scans." [19:32]
+
+## [Cloudflare outage on December 5, 2025](https://blog.cloudflare.com/5-december-2025-outage/)
+
+**Mark:** An interesting side effect of this was CloudFlare had already had a dashboard problem when they DDoS themselves with a use effect and then they. They also had an issue with something else on their backend. I think second or third outage then happened when they tried to roll out a change to buffer sizes in relation to fixing React2Shell, and made themselves go down again for another half an hour. [19:39]
+
+**Carl:** , it's funny how these seem to be kind of unforced errors on Cloudflare's part, like Yeah. , they also were like Johnny on the spot with a blog post saying, we've got a web application firewall that will prevent the worst of this from happening. And then like, took themselves down for a couple of hours. [20:08]
+
+I was reading the, the writeup of this and it sounds like they started seeing elevated errors in a tool that was related to determining production errors. It was a tool partially designed to help avoid the risk of outages. They started seeing error rates rise in that and we're like, nah, this is fine. [20:26]
+
+We're gonna keep going. That, so that seems a little like an unforced, self-owned there, which is un. Silly to me, given how smart me they came across at the very beginning of this vulnerability. Anyway, I'm just giggling at them. [20:46]
+
+## Tech analysis: “Flight Protocol”
+
+**Carl:** Okay. Some tech analysis. I guess I did sort of an abstract tech analysis, but let's get deeper in. [20:58]
+
+**Mark:** The React team is very fond of their project code names that start with f They, they've literally got like two or three dozens of them. So, fiber was the React 16 rewrite. So React Flight is the code name for most of the work that has to do with implementing server components. And so the flight protocol is their custom serialization and deserialization technique that is meant to encode not just data, like , it can, serialize JavaScript objects and, more advanced values like dates and promises and stuff. [21:04]
+
+But it also encodes a lot of the semantics of react components themselves. Like when you put a suspense in there, it puts in a placeholder value that says this will be filled in later, and so on. So there's many other like advanced JavaScript serialization libraries out there like `cereal`, but they built their own because they specifically needed it to handle react related concepts, not just , the data. And so ultimately the vulnerability is in this flight protocol implementation. Not the data format per se, but the process of doing the deserialization. And so because of that, it's a core part of RSC functionality itself, not specific to any one framework, which is why all the RSC frameworks were affected. [21:42]
+
+## Vuln is carefully crafted Promise deserialization + `new Function` eval
+
+**Carl:** Yeah, so I guess the vulnerability here is a carefully crafted promise des serialization and a function eval. [22:33]
+
+So the danger there, like function eval. one of the JavaScript concepts they're trying to serialize is executable code dangerous. this is why if you, this is why you don't use eval. This is why like eval has lint rules saying never use this because 'cause it's so fucking dangerous. So it's not literally eval in this case. [22:42]
+
+**Mark:** It's not the eval keyword, but new function and, and passing in a, a string is essentially the same thing. [23:03]
+
+**Carl:** Slightly different semantics, but essentially the same thing. Executing untrusted code. [23:09]
+
+## PRs: [Initial fixes](https://github.com/facebook/react/pull/35277), [Promise cycles / function toString](https://github.com/facebook/react/pull/35345), [more Promise cycles](https://github.com/facebook/react/pull/35351)
+
+**Mark:** There were three major fixed prs. The first one has the fix for the actual remote code execution vulnerability, and they snuck the fix into a larger PR that did a bunch of other refactoring to try to add just a little more obscurity with what was going on. But I, I saw people quickly identifying which bit of that PR was the actual error. [23:14]
+
+Basically it boiled down to a couple lines that had like, looking up `module[name].something else`. And so just like a generic object field lookup with user provided input for the field names. And the fix was essentially adding a object has own property [23:42]
+
+**Carl:** check [24:04]
+
+**Mark:** around that. And so there were a couple very good breakdowns. [24:05]
+
+## [Guillermo’s breakdown](https://x.com/rauchg/status/1997362942929440937)
+
+**Mark:** Guillermo Rauch, CEO of Vercel posted a, a tweet where he went into some detail on what the actual vulnerability issue itself was. [24:09]
+
+## [Shruti’s breakdown](https://blog.logrocket.com/react2shell-exploit/)
+
+**Mark:** And then Shruti Kapoor had another very good breakdown, and I saw a few others being posted as well. It's one of those things where on the one hand, you look at it and it's like, okay, if you think about it, this is a generic object lookup with user provided input. [24:18]
+
+And at no point was that user provided input sufficiently checked and someone figured out the right sequence to make it happen. On the other hand, Ricky Hanlon also made the comment that figuring this out and crafting the input was incredibly advanced. Like, yeah, in hindsight, maybe some of this looks really simple and obvious, but as Carl said, like it, it took years for anyone to look down far enough and realize that this particular bit of code was vulnerable in [24:36]
+
+**Carl:** Yeah. It's funny, I'm reading this, Shruti Kapoor's writeup of it, and it really reminds me of SVG, , the way this is encoded reminds me of how SVG is encoded. , line one is M1 colon and then a bunch of data. M is a means, this is a module one is the ID for this module. Like, " J0, this is a json chunk with root component ID zero." [25:06]
+
+So I don't know. That's interesting it rhymes with something I've noticed in my career is like, I did some really cool, fun stuff with SVG because when you start looking at the details of how things are encoded, like this, you can do some really interesting things. [25:30]
+
+It's like all the tools will generate a certain type of valid thing based in some assumption, but when you start actually looking at what they're producing and doing it yourself, you find interesting stuff. So, I don't know, that's just, that's what the security researcher did is instead of relying on the compiler to do output for him, he tore it apart, looked at how it actually worked, and then went, "Oh hey, this lets you get arbitrary modules and extract whatever thing you want off it. I bet you can do something interesting with that." Yeah. [25:44]
+
+## Comms critique
+
+**Mo:** I'm curious as to what you guys think about this. Like, I, I'm looking at , the sort of, the quote from Ricky and part of me is like, I appreciate it. It, it is very complex, attack that you need to coordinate at the same time, it feels a little bit, shrugging of the issue, which was a very key, core vulnerability. [26:14]
+
+Right. it's almost like in contrast to CloudFlare, where they're like, "we fucked up. We know we fucked up. We let you guys down. We've lost your trust." Granted they've had to do that a few times now, but , the point is , it just feels a little bit immature to brush it off to say, I don't know, maybe this is just my opinion. [26:31]
+
+I'm keen to hear what you guys think from like a how should open source slash big tech companies handle when I say open source slash big tech? 'cause it's effectively when speaks, kind of speaking on behalf of Meta, right. Whether he likes or not. And it's like, I don't think that that's a constructive way to look at it, to be like, it's quite complex. [26:48]
+
+That's why CVEs are discovered. Hackers and bounty hunters are the best people to discover this. It's like, not quite like, you guys are the maintainers. You should look out for it. It feels a little bit like shrugging off a very, very, very core issue that happened in ecosystem. [27:06]
+
+**Mark:** So on the one hand I think from a, like a security response perspective, the React team and all the rest of the, the hosting companies have done the right thing. There was, some private disclosure happened. Everybody worked out the patches, had the firewall rules ready to go. [27:21]
+
+There was a coordinated release so that at the moment this was publicized, like, there was immediate protection and fixes of Ill, like that is the correct part of the handling. then similarly, as soon as the additional CVEs were discovered, there were follow up posts, tools, created to help bump all your versions. [27:38]
+
+Like all that stuff has been excellent and I think , they've that stuff the right way. On the other hand, as you're pointing out, even from like a perception perspective, , the blog post on the follow up CVEs. Initially, one of the first bits in that post was a call out box that said, "follow up CVEs are a very common thing because everyone, now, everyone is looking at your code." [27:56]
+
+And the React team actually got called on in Hacker News, like, " which is more important, protecting your reputation or giving people the information they need to re-update their tools." And, to their credit, , they restructured the post. So the tech information was first. [28:21]
+
+I I do totally get the preemptive defensiveness. Like of course, the React team and ecosystem are gonna get criticized because, oh no, now there's more problems. Look how bad your code is. I totally get that. I think the comment was, justified. But putting that as the first thing in the post was maybe not the best way to do it. [28:35]
+
+I agree with you that the way the phrasing here and the defensiveness does not look ideal. [28:56]
+
+**Mo:** Yeah. And it's just a phrasing thing, right? It's like, I, I agree with you a hundred percent that it was very well coordinated. They worked with all the right people, all the right hosting providers, and did a good job of tackling a critical vulnerability, right? But then the messaging is a little bit laissez faire, like, let's just, this happens guys. [29:02]
+
+Of course it happens. And so that, that's the bit that I'm just, a little bit it doesn't sit right with me. [29:23]
+
+**Carl:** Yeah, I have some opinions on this., I don't know. This is, deep in the weeds of like communication, effective communication, especially when you've someone wrong. Even that someone is an abstract group of millions who rely on your work. [29:27]
+
+Yeah. defensiveness is never good to lead with Also defensiveness. Is a lot broader than most people think about. If you are offering a reason, a justification, an explanation, all of that is defensive. That is saying, maybe it's not saying :it's okay that this happened because," but it is saying there are mitigating factors. [29:40]
+
+And at the outset while talking about, a problem, a thing, it is never good to offer reasons why you made that mistake. Just like you made it, it happened, it's done, own it.Don't defend it. [30:00]
+
+**Mark:** Which, which I think has generally, as a, counter example, I think generally been one of the strengths of Cloudflare's, you know, outage messaging It's like, yeah, we screwed up, but here's exactly what happened and the things that went wrong. they're explaining the technical reasons, but it's generally factual rather than like communications oriented. [30:16]
+
+**Carl:** yeah. And I wanna, Mo you used the word immature and I think I like yes. In context it's the wrong, it's like wrong. I would reframe it from immature to like, this is crisis comms. This is public relations at a world level security incident. [30:37]
+
+And so while the, while that instance of, defensiveness, especially when you feel that you've done everything you could, you've done your best totally get it totally makes sense. There's a really strong instinct to do that If you're operating at a world class level, the expectation is higher than that. So I guess I would reframe it from like immature to like not meeting the bar of excellence. [30:58]
+
+**Mo:** What Mark was saying was exactly what I was thinking, which is like the CloudFlare posts are exactly how I would rather have this handled, which is an admission of whatever that is an admission we made a mistake or we didn't discover this, I'm sorry. [31:20]
+
+And here's exactly what went wrong that reads as I'm giving you the technical reasons and I'm being transparent with you, rather than I'm defending myself and trying to, to cover up [31:33]
+
+**Mark:** And are all the mitigation steps going forward to improve our process and make sure that this set of problems never happens again. [31:42]
+
+**Mo:** To play the devil's advocate. To my earlier point, I get the emotional instinct to defend yourself. Right? Like it's an open source project. You've chosen to work and benefit off of the work that React and the React team have have been building. I get it, like open source maintainers are not appreciated enough, but you are also a multi-billion dollar company and you need to have some PR instincts as part of that. [31:51]
+
+**Carl:** Or delegate to a PR team. [32:14]
+
+**Mark:** The reactions to this have been incredibly predictable on Hacker News and Twitter and everywhere else, which is lots and lots of, " RSCs were a mistake in the first place. boy, I am glad I never adopted RSCs" and lots of similar threads from lots of people. [32:15]
+
+**Carl:** Can't avoid it. Look at us not doing that. We're so good. [32:34]
+
+**Mo:** Give ourselves pats on the shoulder collectively. [32:39]
+
+**Mark:** We've seen complaints about server components being quote two complex really since the beginning. And like with the word boilerplate people use the word complex or complexity to mean lots of different things. Is it the mental model? Is it the technical implementation? [32:42]
+
+Is it the architectural approach of trying to bridge the server and the client? I mean, diff different people have different pieces in mind when, when they use the word complex. I, I think there, like, there's probably some fair validity to the concerns. We've talked about the mental model of trying to understand if you're looking at a given file, a given function, understanding where is the code running, when is the code running, what are the inputs needing to, if I've got a secret value on the server, how do I make sure that it's not getting accidentally exposed and sent to the client? [32:59]
+
+So, as Carl said, part of this is just, client server behavior is a distributed system. It is a inherently complex thing. And we are trying to solve a complex problem with 50,000 different attempts at abstraction, server components being one of them. So part of it is, this is just a very hard space, but it's probably also legit to say that this particular set of abstractions is complex, both in terms of mental model necessary technical implementations. [33:35]
+
+You know, as always, I feel weird saying this stuff because I'm on the sidelines and so I'm the bystander without the hands-on experience, but just eyeballing things. I think that's maybe a point in favor of something like remix loaders or TanStack Start server functions where you look at a thing and it's very, very explicit: this is the function that runs on the server. And okay, yeah, maybe there's still some bundler magic that's going on to make that feasible be in the same file, but at least there was something in the code that very clearly said where that piece of behavior is intended to run. [34:07]
+
+**Carl:** I'm just saying if this were written using the primitives that Effect-TS offers, then list what environment was required as part of the types, like you could get type level guarantees on this shit. I'm just saying. [34:45]
+
+## [“React is rainbow colored (function types)”](https://bsky.app/profile/sh03.dev/post/3m7tz3zhl522f)
+
+**Mark:** There was one tweet that I saw, which was using the metaphor of different function colors. this concept started as a blog post like a decade ago where someone that sync and async functions are differently colored and that they're, they're essentially contagious. [34:59]
+
+That once you have an async function, it spreads through the rest of the code base. And so this tweet. Was saying, well now we've got like three different colors and they multiply. So now you have to consider like function components, server components, hooks, server side, client side. It was kinda like the multiple kit of factor of all the possible variations in how a thing can run. [35:15]
+
+## What does this mean for React and RSC adoption going forward?
+
+**Mark:** All right, one, one last bit of Opiniony stuff and then we can move on. So what do we think this means in terms of, what's going to happen with React in 2026, but also what does this mean in terms of server component adoption at this point? [35:39]
+
+On the one hand , we've been seeing the positive technical progress in the ecosystem where it, it's getting past the experimental stage in other tools. [35:56]
+
+React Router has added RSC support walkthrough is getting closed to being production ready. Redwood is out there , TanStack Start is looking at RSC support in its own unique way. So we're getting past the point where this is just a feature that's available in Next, and that feels like it's going to be very big for adoption. [36:06]
+
+I think actually React Router support is gonna be huge, but now you've got a vulnerability here and you've got all the naysayers popping up and saying, "ha ha, look. See, I was right. This was a bad idea." So plus and minus, how is this gonna behave? [36:29]
+
+**Carl:** I will say I think the haters are gonna show up no matter what, and the only thing that varies is, there's some variance. There's probably gonna be more haters because of this than there might have been otherwise. But many of those haters would have just been saying something different if this hadn't happened. [36:45]
+
+So I think there's gonna be, I think this is gonna end up being net good because there deserves to be more than an uncritical adoption. Like, you know, when I think about when hooks came out, everyone's like, "aww yeah!" And just like immediately all in. [37:01]
+
+So like it's a rainbow colored functions. It's bunch of complexity. It's difficult to know where code is executing now. It's hard, Next adds on additional caching stuff that adds even more complexity. So I think this might trigger a bit of a reckoning for the folks pushing the state of the cutting edge, the people who are pushing the envelope, I think are going to be forced to offer stronger justification. Forced is wrong, let's say pressured. [37:18]
+
+What do you think would be good, I've said a couple times over the years of doing this podcast that like I view the, the React core team as doing like post-doctoral research in distributed execution of, you know, ui. So with that framing in mind, this is going to ask those folks who are doing the more academically minded whatever to more strongly justify the direction, which I think will be good. And I think, we'll, I would hope will lead to more robust everything. [37:47]
+
+The "react is rainbow colored," I think is like so deeply real and a major limiting factor because you're context switching and like you said Mark, , there's nothing in the code to indicate where it's executing. You have to know it. [38:22]
+
+I'll say that, specifically, the fact that you can't look at the code and understand aspects of it without gathering more context from where it is, is like deeply antithetical to the model of programming that React is built upon, like componentized self-contained, tiny world. If I'm looking at a component, generally, up until React server components I guess, I know that it has everything it needs. Unless I've done something else. [38:36]
+
+Like, okay, CSS can cascade, context is slightly unknown. But like I can look at the guarantee, I can look at the code and statically understand what guarantees it requires from its environment and what it's doing. [39:06]
+
+it doesn't just like reach into other stuff and change things at random. And so with React server components, I can no longer look at a single component and fully understand where it is in the world. So I don't know, hopefully that changes. [39:22]
+
+**Mo:** So we've gone through an, an era over the last couple years where it's been a heavy focus on RSCs, right? [39:36]
+
+And I think someone in the chat as well today asked like, are RSCs good or bad? Right. And I think that's the issue is just because it's been so center stage on every discussion about React. It's almost been implied that everyone needs RSCs, everyone needs next. Anyone who builds a web app needs these tools, and this is the right evolution for everyone in the ecosystem. [39:44]
+
+I personally never believed that that was the case. I think it was a good optimization and a good next step to help take React to certain paradigms and certain spaces where it wouldn't have been suitable for before. But it wasn't the be all and end all. [40:08]
+
+And I've been working with a client where they started off with next JS, in the beginning of the year they brought me in to try to help them a little bit and clean up the next JS app because they weren't next JS developers. They were from a totally different ecosystem and they were trying to understand next, and the app was a mess. And so over the last couple months , we realized, well they don't really have the expertise to be able to manage like a complex next JS app that was quite large in the surface area and handle all of the caching complexities and RSCs as a concept within that development team. [40:22]
+
+And so we switched them to Astro after a while and it's just been a lot easier for them to conceptualize and understand that. And so is this a net good? I actually think it is because like you say, Carl and I completely agree with that. It's, this is going to help us really stop pushing this like, envelope of RSCs are for everyone. [40:57]
+
+And this is by no means me saying RSCs are a bad evolution of react. No, to the contrary, I actually think it was a good route, good evolution, but it's not for everyone. It's not for every site. We neglected single page apps, which are for so many things in pursuit of this RSC Dream, and I think we need to come back to reality and see like, what is the ecosystem in its whole? [41:21]
+
+And start to prompt people to think a little bit before they always reach out for next js for every single project that they wanna do. do you actually need next? Are you having to take on the complexity that next gives when you adopt next? And like it has a lot of benefits, but like, does your site need those benefits? [41:42]
+
+Or are you just doing it because it's what everyone else does? so I honestly think it's, it's a good thing. It will be tough. There will be an adjustment period, but I think it'll, generally make us a bit more nuanced as an ecosystem, which is good. And the bleeding edge is not always the be all and end all. [42:00]
+
+The bleeding edge should be there to help push everyone forward. It's not for every single app that we built. [42:18]
+
+**Carl:** Yeah. [42:24]
+
+I, have an analogy that I love, or I don't know, an analogy, a way of framing that kind of, you just expressed of like the we, the bleeding edge and like reigning it in a little bit there. [42:24]
+
+I think there's a really strong need for two types of work. There's the people who are expanding the range of what's possible, and then there's the people who are bringing that out to everybody else. So like, as you're exploring, like you can't be constrained about what is this gonna look like for, every individual actor. Like that's, if you're exploring under the constraints of analyzing it for every possible possibility, you will never explore anything. It's just too much work. [42:36]
+
+So that needs to happen largely in isolation, in order to happen at all. And then there's a translation. It's like, in entrepreneurial terms, it's the distribution problem. It's how do you get it to everybody, great, you've made a perfect, better mouse trap. How do you get people to know about it, realize it's better, and buy it? [43:02]
+
+Where in this case, buy it is, install it over some other tool. And yeah, so I think we just got a, the naysayers got a much stronger argument. We'll have to see how that plays out. [43:23]
+
+**Mark:** I will tie this back to one of my favorite hobby horses, which is documentation. Maybe I overindex on better docs being the answer to all problems, but it is my answer to all problems. And so, one of the points I've made repeatedly over the course of this year is that the React core docs don't talk about server components meaningfully. There's one page with scattered bits of information, but the core docs have no intro to what are server components, what problem do they solve, why should I use them, when should I use them, which apps and architectures would benefit from server components? [43:34]
+
+And there are some great posts out there that go into a lot of this information. Vercel had a intro to RSCs post. Dan has his explainers on server components from different mental models, but the core docs don't have this. [44:15]
+
+## [When I go back and look at react.dev now […] it feels half-finished](https://bsky.app/profile/nearestnabors.com/post/3maa3cof5mh2w)
+
+**Mark:** And even today I was actually having a, a tweet discussion with Rachel Nabors, one of the original docs authors. And we agreed that the tutorial kind of trails off. [44:32]
+
+It doesn't give you any real world steps on how to apply your theoretical knowledge of components. [44:39]
+
+I don't necessarily think it's the React Docs job to explain everything about web app architecture, but given that React itself is now more than just a view library, that I think there ought to be some guidance in the docs about how to act like, when does it make sense to use these different tools that we're providing you. [44:46]
+
+**Carl:** I like her post saying, when I go back and look at React dev now, and like React, do Dev was her project. She like, [45:09]
+
+what, when it started, as, [45:16]
+
+**Mark:** Her and Dan together. Yeah. [45:17]
+
+**Carl:** Right. Right. And so she says, when I go back and look at React Dev now after having shipped half a dozen more developer education portals since launch, it feels half finished, they're saying. This is part of their early work. They got better at it and now they see room for improvement, which I think is really real. [45:19]
+
+**Mo:** Yeah, a hundred percent. And the earliest like time, we started to actually talk about this this year, which kinda goes into the year recap, but is we, we conversation finally over the CRA deprecation. Like that was the reckoning that started this conversation about what did, what is the React stance on, where is RSC suitable and where is it not suitable? [45:34]
+
+So. It's interesting that we're looping back to this, but yeah, it's, it's been a common theme for the last year. [45:53]
+
+**Carl:** Yeah. And man, going back to my, comparison of like the explorers and the, I don't know, salesmen did, for lack of a better. [45:59]
+
+**Mark:** There are specific like business programmer archetype posts that I've seen that cover this, and I don't know what they are off the top of my head. [46:08]
+
+**Carl:** You are right. But I feel like the React core team is perhaps too heavily stacked with scientists and adventurers and there's not enough entrepreneurs and teachers, like we need more who are bringing this knowledge and like workshopping it to say what is understandable? How can we make people, how can we put words to page that permit people to walk away from it with the understanding we intended. [46:15]
+
+And like there's like, they're so busy figuring out what it needs to be that I don't think they're quite investing the time and energy into ensuring that people understand what they intend. [46:44]
+
+And I guess we've said before, I've said this before, in the podcast, that React spent so long Innu this number one seat of Mindshare. Like it spent solidly, I'd say eight years as like one of the top five hottest technologies in general. And so they didn't need that core team labor of figuring out how to make people understand it because there was a legion of community members where, that was how they were doing their competitive advantage. They were, that's they were getting consulting work is by being a subject matter expert on the cutting edge of React. And like, nobody cares about that anymore. Not literally like I care, you care the people listening to this care. [46:59]
+
+**Mo:** It's not picking people's bills like it used to. And so all of the attention onto ai, so you don't have all of the consultants and all of those people. So it's now the responsibility to react core team to do that. [47:43]
+
+There's a, , there's a person at work who does like technology mapping that is like a little bit more senior than I am, and he spends more time in strategy stuff. So he is more of that entrepreneurial type of person that you're talking about, Carl, and he, talks about like technologies going through this, like these different levels of like genesis, and then growth, and then at the end they become commoditized and like whether we like it or not, react has become commoditized. [47:54]
+
+Like there are. many ways that you can quickly build React apps, whereas like, it wasn't the case several years ago. And so it's it's now there's a point where we need to really document everything and make sure that it's understandable by everyone because there aren't gonna be consultants who you know are gonna be, that you have to pave to do it. [48:16]
+
+It's very accessible to everyone. [48:35]
+
+**Mark:** my last thought on this topic is that, I don't think the React core team has time to do a bunch of additional documentation unless they, significantly change their priorities and maybe they're not the best people to do it. But I was encouraged by discussions with the team at React Conf for, they indicated they are much more interest, they're very willing to have external community contributions to the docs. [48:37]
+
+Obviously, there needs to be collaboration agreement on what the content is, but they're willing to work with people to get that stuff in. [48:59]
+
+**Carl:** yep. Interesting. Yeah, I would, I would like to talk more with you about that actually, [49:07]
+
+mark, Cool. [49:11]
+
+**Mark:** Moving right along. [49:12]
+
+## React Native year in review
+
+**Carl:** Mo can you give us a bit of a recap about React Native this year as our React Native expert [49:14]
+
+**Mo:** I would love to. Thanks Carl. So let's do our React Native year in recap 2025. So I'm gonna start from January and we're gonna do this very quick fire. And I'll, go over the releases, I'll go over some other significant things that happen in the ecosystem. What I will say is, this is not comprehensive. [49:19]
+
+You can obviously go through the podcasts and listen through every single month, I thought I'd pull out things that were significant enough to me personally. So this is by no means a, prioritization of how important things are. It's just what came to mind. And I'll ground them by the reactive releases that went out during the year basically. [49:38]
+
+## [More CSS support](https://reactnative.dev/blog/2025/01/21/version-0.77)
+
+**Mo:** So. January React Native version 0.77. So this one was basically give a high level. There was a lot of focus on styling because CSS is super, super rich in terms of styling that it gives you. And so a lot of effort was put into taking CSS features and bringing them into React Native to help with Layouting, to help with sizing and even things like blending modes, which was really quite cool. [49:54]
+
+So it helped make styling within React Native a little bit more web-like. And that was a trend through a lot of the releases, not just in styling, but in other spaces within this year's React Native releases. Another thing that's worth mentioning was there was a breaking change that seemed to be Initially they thought that it was gonna be quite uncontroversial, which was removing console logs showing in Metro. [50:20]
+
+We'll come back to that in one of the next releases. [50:41]
+
+## [Expo EAS hosting](https://expo.dev/blog/expo-announces-eas-hosting-service)
+
+**Mo:** Same time in January, expo launches their EAS hosting. And so this is expos forte into the universal app deployment world. obviously Expo's been pushing universal apps for the last couple of years and they didn't have a hosting solution for it and things like backend routes and so on and so forth to help you build a full stack application. [50:45]
+
+So they launched EAS hosting as sort of a esque competitor for people that want to build mobile and web apps using the expo ecosystem. And also have basic API endpoints and so on and so forth. So that was another thing that happened in January. [51:04]
+
+## RN 0.78: [React 19 support](https://reactnative.dev/blog/2025/02/19/react-native-0.78)
+
+**Mo:** We move on to February, React Native 0.78. And this was big because React Native was struggling, was kind of falling behind the React ecosystem in terms of adopting , the latest major versions of React. So it was on React 18 for a long time. And so, 0 78 in February gave us React 19 support, which, came with a whole bunch of different things, but you were able to finally use all of the new React features, like actions, like the optimistic and so on and so forth. [51:18]
+
+There was also the React compiler and they started to hint that we're gonna have more frequent releases this year. Now the example that I mentioned, or the point that I mentioned around the removing of logs was reverted this release because of widespread complaints because people are used to seeing their logs in Metro and so they added a flag saying that you can now pass dash dash client logs and get back your logs, which was, was much appreciated by the React Native community. [51:49]
+
+## [Lynx launched](https://lynxjs.org/)
+
+**Mo:** In March no React Native releases, but the folks at ByteDance released Lynx and links was sort of their internal inner source version of React Native that was very similar to React Native in many ways, but was also quite different in terms of how they handled the internals. And was really focused on, getting a quick time to interactive for a mobile app. [52:18]
+
+So this is what's powering apps like TikTok and so on and so forth. So it was quite exciting to see an alternative to React Native and a different take to building cross-platform native apps that followed React Native very closely. [52:40]
+
+## RN 0.79: [JSC moving to Community Package](https://reactnative.dev/blog/2025/04/08/react-native-0.79)
+
+**Mo:** In April, we had React Native version 0.79, and so I'm gonna just highlight one thing out of this release, which was, and of course there was a lot more that happened in this release, but one of the key things was JS Core, which was the old engine, pre Hermes that React Native relied on, moved to a community maintained package. [52:52]
+
+So. Majority of React Native users didn't really, didn't make a difference to them. But for some of those older apps that relied on JSC, it, it just signaled that the React team was really zeroing in on Hermes as the engine to run React Native apps. [53:11]
+
+## RN 0.80: [Freezing the legacy architecture](https://reactnative.dev/blog/2025/06/12/react-native-0.80)
+
+**Mo:** Then in June, two months after we had React Native versions, 0.80. And so this one was big because the legacy architecture, as they put it, or as how everyone sort of referred to it, the old architecture was frozen. And so this was pretty much in, in this world of making the new architecture, the sort of defacto way at the defacto internals of React Native, this was sort of a big deal because it was basically saying , we are no longer gonna be so supporting the old architecture, and we really want everyone to move over to the new architecture. [53:27]
+
+It's been in the making for years. Let's get everyone migrated away. This was sort of the big news for this release. [53:58]
+
+## RN 0.81: [Android 16 support for edge to edge](https://reactnative.dev/blog/2025/08/12/react-native-0.81)
+
+**Mo:** Then two months later in August there was a release of React Native 0.81. This was mainly focused on Android 16 support because there was some drastic breaking changes in the Android ecosystem. [54:05]
+
+So this was API level 36 for you Android developers. And it supported things like Edge to edge support but it also deprecated things like safe area view because there were better alternatives in the ecosystem that were open, open source and really just made sure that that React Native , was compliant with the latest Google requirements for apps, which was to have edge to edge support. [54:16]
+
+## [1.0 on the horizon](https://www.youtube.com/watch?v=GPtopk4y2LI)
+
+**Mo:** Then in September we had a talk from Jorge Cohen, who's one of the engineering managers at Meta in the React Native Core team. And they talked about how 1.0 is on the horizon. So this has been like the brunt of jokes in the React Native ecosystem for a very long time that React Native will never reach 1.0. [54:36]
+
+And so this was a, this was quite fun for us to, hear as a community that, you know, there is a world in which we can reach a 1.0 of React Native. And there are many memes if you search for React Native 1.0 [54:56]
+
+**Mark:** We're not there yet, but at least we're talking about it. [55:06]
+
+**Mo:** It's a great, great move, right? Like it's, at least we're talking about it, which is great. a little bit of an anecdote is, I still laugh when there was a a CEO of a company that we spoke to who we were trying to say, you should go to React Native and not build two separate native apps. And he said to me, point blank, that "my friend told me that React Native is so un unstable, it's not even version 1.0." And that still makes me chuckle. How decisions are made. Cool. [55:09]
+
+## [Vega OS launched](https://developer.amazon.com/apps-and-games/vega)
+
+**Mo:** Same time in September the folks at Amazon lifted the veil on something that they've been working on for a number of years, which is a completely new operating system that is built from the ground up to support React Native. [55:36]
+
+And so they call it Vega Os. I have known about Vega OS for a little while and have been working with some of the folks at Amazon behind the scenes. But Vega OS will power the next generation of Fire TV devices and other devices that Amazon makes. And so this was really quite cool because the only way and the defacto way that you build apps for this new operating system is with React Native. [55:48]
+
+So it's a big bet on React Native's future and long GI longevity as a technology, which was really, really cool to see. And it just shows that this ecosystem is only growing and expanding. [56:11]
+
+## RN 0.82: [Only new architecture](https://reactnative.dev/blog/2025/10/08/react-native-0.82)
+
+**Mo:** Then in October we had React Native version 0.82. Now this one was also a big one in the world of new architecture releases because this was a release where they removed the legacy architecture. [56:22]
+
+And so basically they were saying that this version will only run on the new architecture. You'll need to adopt the new architecture to be able to use it. And they're gonna be removing for future releases. All of the components in the code that rely on the legacy architecture. [56:35]
+
+## [Expo App Awards](https://expo.dev/blog/2025-expo-app-awards)
+
+**Mo:** Also in October we had Expo launching their 2025 Expo app awards. [56:50]
+
+So this was the first time they were doing this, but it was actually quite cool and I think it's notable to talk about it, which is, Expo sort of in, in Apple-esque fashion of, let's do an app awards for the year. They basically opened up nominations for people to, to nominate any apps that have been built with React Native and Expo. [56:56]
+
+And so we saw a lot of cool apps come from different parts of the world and, and basically say, Hey, we use React Native, we use Expo. And so it was a really cool uh, it was a really cool showcase and I think it's a really good collection of really top class well-built, well-designed apps that have been built with React Native and having something like that available as a reference is really cool when you're talking to people about why React Native is a great technology to be building your apps with. [57:12]
+
+## RN 0.83: [New Devtools - no breaking changes](https://reactnative.dev/blog/2025/12/10/react-native-0.83)
+
+**Mo:** And finally, and we talked about it in the new releases going to December, we now have React Native version zero point 83. And so the key things to highlight with this, as we mentioned, is the new dev tools and that there are no breaking changes, which is very, very exciting for the React Native community to not have any breaking changes and have a smooth update process. [57:39]
+
+And so that's the yearly recap for React Native. And I hope it was tac enough and I didn't bore the audience with all of the releases and all of the numbers that start from 77 and go up to 83. [58:00]
+
+**Carl:** That's a lot of releases! [58:11]
+
+**Mark:** I would not have known enough to, pull in most of those items [58:12]
+
+**Carl:** that's a lot of releases. I mean, we got six releases in 12 months, like hot Damn. That's [58:15]
+
+**Mark:** every two months. That's solid. [58:20]
+
+**Carl:** Do you know when it was first released? [58:21]
+
+**Mo:** React Native's. First release was 2015. [58:23]
+
+**Carl:** Okay, so that's 10 years, 83 versions in 10 years. That's, I guess that's eight per year, so, oh, if they're slowing down, how dare they? [58:25]
+
+**Mo:** So, so there was a very, very fast start at where very, very like quick, quick releases and then um, it slowed down to several months before there was a release, and now they're sort of standardizing it at a release every two months, which is quite good because, you know, that's something that's more maintainable and manageable and makes it less painful to do the updates. [58:32]
+
+So if I've done my math right here, if we do the a hundred divided by 83, that's 17 divided by six releases. So we're talking three years before, if they just continue on the succession, 1.0 might be there in 2.8 years. or they do 0.1 hundred and then we all have a good laugh. [58:53]
+
+**Carl:** Yeah. I'm just pulling it up real quick. Version o one initial public release was March 27th, 2015, and they had version 0.10 out by August. So yeah, that's 10 releases in like three months. So that's, entirely different type of release. Yeah, man. They're on version 0.40 in 2016, like a year later, [59:10]
+
+that Doesn't really mean anything, but that's just some fun uh, It's interesting this, it's professionalizing, you got this prototype that, oh, look at works. [59:32]
+
+Oh, it's broken. Oh, it's broken. Oh, it's broken. it's like a stable ish product with a release schedule and all that kind of stuff. It's cool to see. [59:40]
+
+**Mo:** I wouldn't say stable ish. I'd say stable. don't undermine the community like that, Carl. [59:49]
+
+**Carl:** According to SemVer, a zero major version you're you are allowed to release breaking changes without a major revision. [59:54]
+
+**Mo:** you're telling me the CEO was right all along. It's not stable until it's 1.0. Right. [01:00:01]
+
+**Carl:** I'm just saying. technically that's what the contract says. [01:00:05]
+
+**Mo:** Technically, that is what the contract says. You are. You are absolutely right. [01:00:08]
+
+So yeah, it was lovely as always. Have a lovely holidays to everyone who's listening and enjoy whatever festivities you're celebrating and we'll see you on the other side. [01:00:12]
+
+**Mark:** you very much, Mo. Merry Christmas and happy holidays to you too. [01:00:22]
+
+**Carl:** Cool. Okay, wonderful. [01:00:25]
+
+## React year in review
+
+**Mark:** Semi rapid firing our way through the myriad of stuff we have left. [01:00:27]
+
+## [CRA deprecation](https://github.com/reactjs/react.dev/pull/7495), [new install docs](https://react.dev/learn/build-a-react-app-from-scratch) (Vite!)
+
+**Mark:** We, we started the year in React land with React 19 had just come out in December of 24, and that's when I noticed everyone's CRE React app projects were breaking. And I will still take 75 to 80% of the credit for the actual deprecation process happening here. [01:00:32]
+
+Theo had put up his post complaining about the docs a couple years ago. Dan had written his response saying, don't use CRA, but I take credit for complaining loud enough for noticing the problem and complaining loud enough and filing the issue and pushing them to make this happen, which is also how we actually ended up with the React Docs actually now listing Vite, RSBuild, and Parcel, and do it yourself tooling as a valid, officially documented, supported way to do a React project, not just use a framework. [01:00:51]
+
+So I actually legitimately take credit for that one. [01:01:26]
+
+**Carl:** I give credit for that one. Yeah. yeah, we, so we start with Create React App deprecation, much better new docs. [01:01:28]
+
+## [Styled Components Deprecated](https://opencollective.com/styled-components/updates/thank-you)
+
+**Carl:** We move into styled components getting actually officially deprecated. [01:01:35]
+
+**Mark:** That had kind of been on the horizon because of the changes with server components and not having contact support in a server components environment. Which, kind of also goes back to the, the mental model and like, even if they're not pushing server components, technical changes and having to keep up change on the ecosystem [01:01:38]
+
+## Releases: [19.2](https://github.com/facebook/react/releases/tag/v19.2.0) (Activity, useEffectEvent), [Compiler 1.0](https://react.dev/blog/2025/10/07/react-compiler-1)
+
+**Mark:** So the, big react release this year was 19.2 in the fall, which included the, the final actual release of the activity component previously offscreen, and the new confusingly named use effect event hook. [01:01:59]
+
+And then along with that at React Con, the react compiler finally hit 1.0. It had been an RC for a while and now it's finally officially, officially available. , it'll be still very interesting to see what the adoption rate is on that. I, I have no metrics. I've not looked at download numbers or anything. But I, feel like it's gonna need official integration into build tool chains to really start to take off, otherwise it's still kind of piecemeal. [01:02:12]
+
+## Research: [View Transitions canary, perf, concurrent stores](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#view-transitions), [“throw a promise” deprecated](https://github.com/facebook/react/pull/34032) (but not merged yet)
+
+**Mark:** On the API research side we had the canary release of view transitions. We've got the ongoing concurrent stores work that I am very personally excited about and involved in. We saw a mention of killing off the existing throw a promise method for triggering suspense now got the use hook available. [01:02:39]
+
+## “[Async React](https://github.com/reactwg/async-react)” and the ecosystem
+
+**Mark:** Also at React conf Ricky Hanlon's talk on Async React, I think was one of the biggest pieces of messaging from the React team. We've spent all these years building the new features, suspense, transitions all the other stuff. What does it mean in terms of coherent usage? How does it change the code that you'd write versus a 2018 ERA app? [01:03:00]
+
+What does it mean in terms of, well, you know, ecosystem libraries like component libraries and routers and state management tools ought to just do the transition calls for you so you don't have to write them in your own code. I think we're gonna be digesting the implications of that one for quite a while. [01:03:24]
+
+## [React Foundation](https://react.dev/blog/2025/10/07/introducing-the-react-foundation)
+
+**Mark:** Then at React Conf, we also had the mic drop announcement of the React Foundation that reacts ownership is finally after years and years of speculation. And boy, I wish they would actually moving from meta to an independent foundation, part of the Linux Foundation, with multiple companies providing financial support, board governance, and technical support as well. [01:03:41]
+
+And then I, I found out some more details from Seth Webster at React Summit that, they'd been working on this for like four years and had even held off on trying to do the announcement for a while because they wanted to make sure that they were working on they, that, that their internal day-to-day process of development was essentially beta testing the process that they're going to use as things become more public. [01:04:10]
+
+And the comments that down the road they want to make the development of its of react itself fully public, the weekly meetings bringing back RFCs as a means of getting proposals. So the development of React is going to change significantly as we go forward. [01:04:34]
+
+## [React growth skyrockets](https://bsky.app/profile/sebastienlorber.com/post/3mabj2vg23c2l)
+
+**Mark:** We've also had all the rise of all the different AI powered build tools, which are using react by default. 'cause that's what LLMs are trained on. A lot of that is based on Vite of course, next V0 is using next, but Vite is the default for a lot of these. And so the growth charts for React are absurd. [01:04:53]
+
+**Carl:** It is absurd. there's a visible inflection point. I don't know. It's, it's funny, there's actually like two— [01:05:13]
+
+**Mark:** like January this year is when all the AI tools took off. [01:05:18]
+
+**Carl:** Yeah. It's funny 'cause there's a certain, very consistent, I would say exponential growth curve from like 2015 to 2023. And then it's funny, there's like a little kink down. Like stops growing quite as quickly until January of this year and then it fucking rockets. So that, I don't know. That's interesting. [01:05:21]
+
+So I wonder if people stopped, like the pace of new projects actually got hampered by initial AI tools. 'cause maybe I, I feel like people may be, I dunno, this is speculation, but I feel like people wanted them to be able to do more than they could and actual as evidenced in download numbers, pace of development slowed and maybe they got better. [01:05:39]
+
+I don't know. This is fun. It's just interesting to look at some data and see some patterns. [01:06:01]
+
+## [React Router RSC support](https://remix.run/blog/rsc-preview), [TanStack Start WIP RSC](https://x.com/tannerlinsley/status/1983999424486633931), [Waku](https://waku.gg/)
+
+**Mark:** As mentioned earlier, we're seeing other tools working on RSC support, and I think , the biggest one is React Router officially bringing out RSC support in framework mode. I think that's, gonna be one of the biggest pieces of, of adoption outside of next we've seen a bunch of other frameworks with RSC support in some form Parcel Redwood walkout, et cetera. [01:06:05]
+
+Tan Stack start is teasing RSC support, and I have seen Tanner gave me a demo and I think it's gonna blow people's minds once that officially comes out just because it's so different and yet it works. [01:06:25]
+
+## Dan’s RSC explainers (he [had](https://overreacted.io/jsx-over-the-wire/) [a](https://overreacted.io/impossible-components/) [bunch](https://overreacted.io/what-does-use-client-do/) [of](https://overreacted.io/one-roundtrip-per-navigation/) [things](https://overreacted.io/progressive-json/) to say)
+
+**Mark:** Dan went on a whole series of blog posts back in the spring where he put out like 10 different posts trying to explain our server components from first concepts, different mental models. [01:06:37]
+
+Here's another explanation. Does this explanation make rses click for Is it a GraphQL replacement? Is it a backend for front end? Is it serialized? JSON and. I would love to see a lot of these, like some form of this added to the docs somehow. [01:06:49]
+
+## [Remix v3](https://remix.run/blog/remix-jam-2025-recap) (not React but relevant)
+
+**Mark:** We had the React Router remix team, Ryan Florence and Michael Jackson teasing us for months about what remix V three would look like. [01:07:07]
+
+Was it going to be a fork? WW would it use preact? Would it be a fork of preact? Iframes something somehow. And then they eventually had remix conf and dropped the details. And it's a weird hybrid mix of react and backbone and a few other things mixed together. It's clearly not, it's literally not react, but there's a lot of overlap. [01:07:17]
+
+No idea how that one's gonna get adopted, but it's clearly like they clearly have their idea and they're going with it. We had numerous arguments over directives and bundlers and mental models and complexity. Use client use, server use, cash use, use, use, use, use, use, use, use, use, use, use. Yeah. [01:07:43]
+
+## Mark went from frustrated ([CRA](https://blog.isquaredsoftware.com/2025/06/react-community-2025/)) to excited (ReactConf, foundation, team efforts
+
+**Mark:** And finally, speaking purely for myself, I started the year feeling very frustrated. I, put a lot of emotional energy into like the Create React app, deprecation and trying to convince the team to change the docs. I even spent a while writing a blog post that I fortunately never actually published because it was too ranty and would've caused problems. [01:08:08]
+
+I was very frustrated with the direction of React early on, but I can say that React Con completely changed my outlook , on where things are going. The technical progress is great compiler and 19.2 and performance research, that's all cool. [01:08:30]
+
+The foundation I never saw coming. And the fact that they finally were doing it like even, like, even just the, the slide, seeing them say the words React Foundation tells me a lot about the intent and what been trying to do. And it, and like, it was only afterwards that I got a sense of how many years they've been working on this. [01:08:48]
+
+And then on an individual level, like I got to talk to several React team members who basically said, we don't get any credit for doing community rated related things in our meta performance reviews. And so things like. The Async React working group and, doing, like a lot of the other stuff that they're doing shows me how much they care about keeping React, working for the community. [01:09:09]
+
+, I've got my gripes, everyone's got their gripes. Nothing's perfect, but it's not for lack of effort and care on their part, and that's the part that actually encourages me the most. And so, the react to shelf vulnerability is a big bummer and it's gonna cause problems. I, Carl and I were briefly chatting with Ricky and as Carl said, hug ops. [01:09:36]
+
+I, feel a lot of sympathy for what they've been having to go through the last couple weeks. But yeah, even with that in mind, I am actually excited and positive about the direction of React itself going into 2026. [01:09:59]
+
+**Carl:** Yeah, I think I would agree with that. I, I read your blog post that you never published. I printed it like an attempt at like, editing and maybe salvage parts that were less ranty and, you know, salvage seems mean, not salvage, but help process. And yeah, it was not inaccurate. [01:10:12]
+
+So , I would agree. I I never saw the foundation coming. , it's like retroactively, I don't know, validating or like. It's good to know that they were thinking about this for a long time. I relate to the thought of exploring an idea and then realizing like, "oh, in order to do this, , in order to accomplish our goals here, we have to do this hard project first." That rhymes with a lot of things I've done in my life. [01:10:29]
+
+And so, like fuck yeah. For putting the work in, like working for several years to like test the process and yeah. I mean, I guess we'll see, Remains to be seen quite how successful they were at that. [01:10:56]
+
+**Mark:** But I absolutely respect the intent and the effort to make that happen. [01:11:10]
+
+**Carl:** yes, it is a massive amount of effort. Like, it's tough. Well, I'm excited to see how that goes. [01:11:14]
+
+Yeah, it's been an interesting year. I don't know. I'm trying to think of how to like summarize this year. ' cause like we've been talking about server components for a long time. I still don't have firsthand experience with them. [01:11:19]
+
+**Mark:** neither. 'cause I don't write, I don't write front end apps these days. [01:11:33]
+
+**Carl:** Yeah. I just saw somebody chatting about maybe I need to just pair program with Effect, so I understand it and I was like, Ooh, you're the person who talked about RSCs and like, maybe we should just do a knowledge transfer there. So maybe I'll do that. But yeah, it's been quite a year. [01:11:36]
+
+I don't know. In some ways it's like legitimizing the fact that they've had a major vulnerability in React is like somewhat legitimizing, like, welcome to the party, welcome to the list of world class engineering projects that have caused security people a huge headache for a day. And the rest of the ecosystem headaches for months. [01:11:51]
+
+But Remains to be seen. If it actually is good, I guess we'll just keep paying attention to it and talking about it on the air. [01:12:12]
+
+## ⚡ Lightning round ⚡
+
+**Mark:** All right. Well, how do you feel about just lightning rounding everything from here on out. [01:12:19]
+
+**Carl:** Let's blast through it. [01:12:23]
+
+## [TS 7 progress update](https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/)
+
+**Mark:** One of the big announcements from earlier this year was that ts was being ported to go and it was gonna be released as TypeScript version seven. And so the TypeScript team put out a big update post, basically saying that there will be a TS 6.0 based off all the same current code base. [01:12:24]
+
+There will be a bunch of deprecation and strict mode changes and other, like, we think modern type script should be written this way. Settings changes. And then there will be no TS 6.1. The next big release would be TS 7.0, the native built. So great to see both progress being made and that this is happening and that, , we have a direction for all this stuff. [01:12:40]
+
+**Carl:** Very cool. Yeah, quick roundup of some GitHub, this all fits under a Microsoft umbrella, funnily but NPM, GitHub, some user experience and whatever stuff. [01:13:07]
+
+## [NPM classic tokens revoked](https://github.blog/changelog/2025-12-09-npm-classic-tokens-revoked-session-based-auth-and-cli-token-management-now-available/)
+
+**Carl:** So, NPM, after several vulnerabilities actually revoked every classic token. Classic tokens are no longer valid at all. Which should make generally, like they had to do that because of all of the vulnerabilities that were, all of the phishing attacks that we're targeting well-known maintainers. [01:13:17]
+
+So like this needed to happen because it had become clear that NPM maintainers had been hacked in a much, much greater quantity than had been, than those tokens had been used. There was a follow-up attack like two weeks later because, like GitHub and NPM, GitHub, who owns NPM (and is owned by Microsoft) put out a notice that they were going to revoke all of the tokens because of this problem, which is wonderful, and you need to give people time to respond to that and update their code and prevent downtime and whatever. [01:13:37]
+
+But it also gives the attackers who have those compromised tokens, a window of time in which to use them. And so that did happen. They did in fact, use more of the tokens that they had previously collected, I think like one day before they got invalidated. So, eh, that sucks. But should stop happening. [01:14:08]
+
+This is a huge positive change. Hopefully this means that 2026, we will not continually be reporting on yet another new vulnerability in NPM publishing. Maybe. [01:14:25]
+
+Also you should consider using PMPM because it lets you do things like minimum delay time before you start using a new version that was released and also lets you, I think by default it does not run post install, or there's various scripts that open vulnerabilities that PNPM does not [01:14:37]
+
+**Mark:** I, I actually went through what week and a half ago my own Redux Library Publishing workflow. I, I'd always done all my releases locally and we had set up a GitHub actions workflow a while back, so some of the other maintainers could publish more easily. Turns out those releases got tagged with Trusted, and then I did more releases locally that were not, and we actually had a couple people complain that PNPM said, oh no, Redux Toolkit isn't trusted anymore. [01:14:55]
+
+complaining about that. So I actually, with that and with the token deprecation, I actually went through a week and a half ago and did a bunch of GitHub actions hardening changed some of the publish workflow and figured out, okay, what I can do is I can use Release it to do the tag and push, and then I will actually kick off the publish itself as the a, the workflow in the repo. [01:15:25]
+
+And so then it's actually trusted and tagged according, and flagged accordingly. [01:15:51]
+
+**Carl:** Interesting. Oh, that's funny. That's deep in the weeds. [01:15:55]
+
+**Mark:** Basically, I'm not doing the literal publish step for my own machine. It's happening from within GitHub actions. [01:15:58]
+
+**Carl:** Got it. Cool. Interesting. Yeah. [01:16:04]
+
+## [GitHub Actions planned work](https://x.com/jaredpalmer/status/1998821983904243918)
+
+**Carl:** Well, speaking of GitHub actions, Jared Palmer, who is a, like pretty, he's a huge name in React. [01:16:06]
+
+He did formic, he did turbo repo. He did turbo pack. He worked on V0. [01:16:11]
+
+I actually did a job interview with him circa 20, oh my God. 17. And yeah, holy shit. Jesus. And he was, he is genuinely a very sharp dude, so I am not at all surprised to see him. [01:16:17]
+
+Take the reins in a more serious capacity. Like he was doing, like I met him when he was working like at his dad's business, and then he did his own business, and then he did like three more businesses before working for Vercel, and now he's fucking PM of one of the most visible parts of the developer world. And like yeah. [01:16:31]
+
+Earned it so thoroughly earned. Fuck yeah Jared. And I love this because he's immediately coming through and talking about a bunch of things that I've wanted to see in for a long time. [01:16:49]
+
+So like, GitHub actions, they're great, but they're, they all, they're also awful. They enable so much great stuff and I hate using them. He was responding to uh, the Primo Gen who was a very prolific tech YouTuber as well as uh, Jamon Holmgren, who, fun fact, previously sponsored this podcast, with a really long, basically a blog post on Twitter with citations talking about the work that they're looking to do to make GitHub actions better in general. [01:17:02]
+
+So that's really cool. Like, I'm gonna see if I can quickly summarize some of this. Eh? Oh, this is like, no, these are pretty deep [01:17:31]
+
+**Mark:** in in, in the weed stuff. But they, intend to do a lot of stuff to make GitHub actions better at a technical level. [01:17:38]
+
+## [Github Action pricing change](https://resources.github.com/actions/2026-pricing-changes-for-github-actions/) and [immediate about-face](https://x.com/jaredpalmer/status/2001373329811181846)
+
+**Mark:** Unfortunately, shortly after that, they also announced a price increase for both standard GitHub actions and cases where you're using GitHub actions to kick off your own job runners. [01:17:44]
+
+And the the reasons listed were understandable, like it takes money to run the control servers, even if they aren't the ones executing the actual jobs. But the way they announced that this got a bunch of blow back, and so like 24 hours later, they're like, Nope, nope, Holt revert, undo, cancel, cease desist. [01:17:58]
+
+**Carl:** yep. Which again, like I gotta say, Jared Palmer was the one messaging that, and I think he did a good job. Like, he says, "we missed the opportunity to gather feedback from the community ahead of this move. , we'll learn and do better." And like, we were talking about, like not being defensive earlier. Like, this is a great example of like not being defensive, just saying like, yep, here's what we did wrong. We get it, we're gonna do something differently. Love it. great. [01:18:19]
+
+Yeah, on the pricing there was a lot of, you know, low effort punches below the belt in the vein of like, "how are they gonna charge for self-hosted runners?" [01:18:42]
+
+And it's like, well come on. Like, alright. It's not their CPU time, but like, you're taking advantage of. A lot of other infrastructure to get to the point where that runner is executing on your code. Like sure, the marginal cost. [01:18:53]
+
+**Mark:** Free infrastructure will always be abused. [01:19:07]
+
+**Carl:** right, right. Anything always has two things. It's got the, the marginal cost of running it, and then it's got the capital expenditure of building it and they built the fuck out of this and they're still building it. [01:19:09]
+
+So like, no, it's not free. It's not free just because you are covering the marginal cost. So, settle out, settle down. If somebody says this should be free because I'm running it on my server, like, chill the fuck out. You don't understand how business works. You're too narrowly focused on the one technical aspect. Broaden your perspective. [01:19:19]
+
+## Stacked diffs [proposal in the works](https://x.com/jaredpalmer/status/1999525369725215106)?
+
+**Carl:** Anyway. Last thing on GitHub. So excited. One more thing from Jared Palmer. Yay. They are sending out a proposal for Stacked Diffs. If you're not familiar with, if when I said Stack Diffs you didn't go, "oh my God, they're doing it," then, stacked diffs is a way of communicating to GitHub that this PR depends on this PR, which depends on this pr, so you, you can do this yourself. [01:19:40]
+
+You can branch off main, do some work, push open a poll request, and then from that branch continue doing new work and push another [01:20:05]
+
+**Mark:** On a third, on a second branch. [01:20:16]
+
+**Carl:** Right, based on that first branch. So like, you do, let's say you commit four times and you push that branch, then you do another branch that includes those four commits that are not yet merged yet and do four more commits and you push that and make a pr. [01:20:18]
+
+, that is my preferred way of working. I really like saying, "I made these changes. They're ready for review. I'm gonna keep using them locally while review happens, and CI and cd, all the validation steps, but I'm gonna keep using it." So my next change is I don't have to reintegrate them after this merges. [01:20:33]
+
+And it is a really frustrating dance to do on GitHub because like, I, I also like to do squash and merge. So that I have like, great, here's the record of every change I made in the pr, but I only care that about the one higher level change. It's, I'm thinking about it in a different level of, of abstraction after it merges [01:20:55]
+
+**Mark:** and then when you merge the first pr, the four actual commits get squashed to a new commit. And then the second PRS branch now has no relation to the history. And how do you keep track of it? How do you update the second PR to now point to main da, da, da, da. [01:21:15]
+
+**Carl:** And in my experience, I have about a hundred percent incidents of merge conflicts after that, because they're technically different. Commits Git does not know that they are the same changes. It just knows that two branches touched the same lines of code with different commit hashes. So like, I don't know, that's a conflict. You gotta fix it yourself. [01:21:30]
+
+So, basically it just sucks. You have to go through, like, you have to like check out the branch in your local computer [01:21:51]
+
+**Mark:** Reset it, re push, something. [01:21:58]
+
+**Carl:** Skip the commits that got squashed, push that, check out the next branch that was based on that branch. You just now updated and pushed and like, it was just a really manual dance of going through every single time. [01:22:00]
+
+And I, that has been my preferred mode of working since 2016. Like stacked diffs is a term that I have used to describe my workflow for close to 10 years at this point. And people have been demanding it on GitHub for almost that long. So like, to see this actually happening is like, I feel like the Rand Paul gif it's happening , I'm so excited. This is so good. [01:22:12]
+
+Well, I'm excited to see the possibilities. We'll see what actually happens. [01:22:38]
+
+## [Anthropic bought Bun](https://bun.com/blog/bun-joins-anthropic)
+
+**Mark:** And then one last ecosystemy thing, and it's amazing that so much happened this month. It's almost an afterthought at this [01:22:42]
+
+but a, a very small company called Anthropic bought a little known tool called bun. [01:22:49]
+
+**Carl:** Woo. Yeah. Great. there's some chatter about like, what, this doesn't make any sense. But apparently Anthropic has invested pretty heavily in using Bun in Claude code. And I don't know exactly what precipitated this deal at this time, [01:22:57]
+
+**Mark:** might have even just been like literally like them chatting in person or something. [01:23:12]
+
+**Carl:** actually, if I recall correctly, the, the Bun blog post actually goes pretty, it speaks pretty candidly about why they did this. And the, the TLDR is that they are a venture backed business. They took funding and that means that they need to return a multiple to their investors. They need to exit as a business, they need to provide liquidity to their investors at a multiple of what they took. [01:23:16]
+
+Which means either building a business that makes enough money that people value it higher than what it was created for. Or you build something valuable enough that a larger business that is much larger and successful and producing revenue and whatever sees you and goes, we need this. We need this so badly, we're gonna buy it from you and it's ours now. [01:23:39]
+
+And so that's what happened. This was an acquihire situation. Bun did not have revenue. They did not have a business plan. They did not have a path to revenue or a path to a business plan. The closest they ever had was sell one day. [01:24:02]
+
+And I think that made a lot of sense in 2022, and it makes a lot less sense in 2026. [01:24:14]
+
+So I think it was the writing was on the wall. Presumably there was some kind of like funding milestone or, runway check-in that they did and we're like "uhoh" and chopped it around. Got acquired. Love it. [01:24:20]
+
+It's great. I am happy to see open source capture value. Open source is really bad at getting anything close to the value it generates in the form of money for its maintainers. So I'm happy to celebrate any instance of that happening. I hope it will happen for more people. I. Cool. [01:24:32]
+
+## [SVG Clickjacking](https://lyra.horse/blog/2025/12/svg-clickjacking/) (SVG filters as logic gates??)
+
+**Carl:** I wanna talk about this. SVG ClickJacking. This is really [01:24:52]
+
+**Mark:** Go for it! [01:24:54]
+
+**Carl:** Who published this? I wanna credit them by name. I guess they only introduce themselves as Lyra, so that's all I will name them as. But they, they appear to be doing, they appear to blog about some security things in general. [01:24:55]
+
+And this is like such a fun exploit. This is taking [01:25:08]
+
+**Mark:** It was an insanely good post. [01:25:11]
+
+**Carl:** yeah. Such a good post. Like I talk about how I love reading technical write-ups about things, and this is like a legitimately novel exploit technique using a tool that I would've never considered to even have a risk of an exploit of this caliber. [01:25:13]
+
+Anyway, so it's, they're using SVG filters, which let you do some fancy visual effects on your website in, in general, [01:25:31]
+
+**Mark:** like calculating pixel colors, basically. [01:25:40]
+
+**Carl:** the first thing they do is like, "oh, we can use this to make liquid SVGs" because it lets us do fun, like shimmery effects because of how you can access the pixel data on your webpage on. And like, , it's rare. There are not that many tools on the web, like not many platform features enable you to retrieve pixel values of the rendered page. [01:25:43]
+
+Like that's not trivial to do elsewhere. , and anyway, summarizing all of this is to say that an old vulnerability known as ClickJacking, where, it used to be that like in the nineties you would go to click like an okay button or like a download button, and secretly there was a layer on top of that that you couldn't see that was, injected by like a malicious advertisement and you thought you were clicking download on this thing, but you were actually clicking download on malware. [01:26:05]
+
+And that's been pretty effectively defended against for 15 years, I would say. Like iframes got, really the reason iframes are so clamped down is because there were a bunch of possible ClickJacking attempts like attacks using iframes. And so this is a new way, the, the way that SVG filters let you inspect pixels and modify, modify the visuals for a certain output. [01:26:34]
+
+Lets you layer things over in ways that you couldn't do be, you can't do any other way. So it's a, it's a, an old attack that I had generally considered to be like, I don't think about this anymore. It doesn't happen in my experience. Like, I have never encountered this professionally. Here's somebody doing a writeup explaining how to do it with a brand new technology. [01:27:01]
+
+This is a really, really fantastic writeup. I would absolutely recommend reading it because it's like fun and silly and genuinely cutting edge and cross domain because it's really advanced security stuff using on visual things that I would've never thought had a security [01:27:19]
+
+**Mark:** The phrase that got me was, they were treating pixel analysis and creating like and NAND or Logic Gate equivalents out of SVG filters. [01:27:36]
+
+**Carl:** Yeah, right. Oh, oh my God. [01:27:47]
+
+That's crazy. [01:27:50]
+
+With demos in the, blog post. [01:27:50]
+
+Yeah. like not only is this a really interesting security attack, and not only is the writeup really effective, but it's also a really technically well produced blog post. So, I don't know, just like this is, this like, came outta nowhere. I've never heard of this person before. [01:27:52]
+
+It's like a nineties esque style and everything, it's a really phenomenal blog post. Highly recommend. Anyway, that's way too much time for one So much for lightning, this stuff. [01:28:06]
+
+**Mark:** Okay, moving right along. [01:28:15]
+
+## Dan Abramov’s [RSC Explorer](https://rscexplorer.dev/), [accompanying blogpost](https://overreacted.io/introducing-rsc-explorer/)
+
+**Mark:** Dan Abramov has put together a server component explorer that lets you see examples of an app and the data and the progression of the loading. And he also put up a blog post explaining why he built this and how it works, and some links to example demos as well. [01:28:16]
+
+## Instant-loading Github repo explorer using RSCs: [Without the blue bar](https://wtbb.vercel.app/)
+
+**Mark:** in speaking of meaningful uses of server components, somebody built a clone of the GitHub repo code Explorer view entirely using server components. And I clicked through a couple repos like the react repo using this viewer. It loaded instantly, like I stunned at how fast it was in comparison to like the actual GitHub Like that right there is actually a powerful example of why server components could be useful. [01:28:36]
+
+## [React Router’s Take on RSCs](https://www.epicreact.dev/react-routers-take-on-react-server-components-4bj7q)
+
+**Mark:** And then Kent C Dodds put up a blog post with his thoughts on why he likes React router's approach to bringing in server components. [01:29:10]
+
+## [How AI Coding Agents hid a Timebomb in Our App](https://acusti.ca/blog/2025/12/09/how-ai-coding-agents-hid-a-timebomb-in-our-app/)
+
+**Mark:** Changing topics. An author who I had not seen at all, but I, I looked up his name as Andrew Patton, put, put up two very good blog posts just like within the last week or two. [01:29:19]
+
+The first one was titled How AI Coding Agents Hit a Time Bomb in our App. And the actual technical problem in here was that they were using the new activity component in their UI and activity does rendering in the background. And AI made a tweak to change something and it ended up doing recursive rendering of their footer component. [01:29:29]
+
+But because the footer component rendered the footer component rendered, the footer component rendered the footer component. This was all happening invisibly in the background until the app ran out of memory and exploded repeatedly. And so it's both interesting in terms of, here's a real world use of activity and also here's a problem that can come up and, huh, wow, background rendering, huh? Okay. [01:29:55]
+
+**Carl:** I'll say before we move on from that earlier I talked about how React was basically a scheduler. , this is why. Like, they wanted to avoid tearing and crashes and things like that. they said in the blog post that they took out the activity wrapper in it and it instantly crashed. [01:30:18]
+
+Like, because it's recursively rendering out of memory immediately. But with activity, because React is such a good scheduler, it managed to stay functional for minutes before crashing because it's evaluating what resources are available and doing work only when it doesn't interrupt the user. So what naively is an instant crash, sustained along for minutes because React is such a good scheduler. Anyway, it's cool. [01:30:32]
+
+## [React Compiler’s Silent Failures (And How to Fix Them)](https://acusti.ca/blog/2025/12/16/react-compiler-silent-failures-and-how-to-fix-them/)
+
+**Mark:** The same author just put up a post a couple days ago talking about how they've been using React compiler in production for a while, and how the compiler does have some limitations in terms of bits of JavaScript syntax or patterns that it struggles with. I think one of the, one of the examples they gave was if you destructure props into your component, but then you reassign a different value to that same de structured variable than the component, the compiler will give up and bail out and not optimize that component. [01:30:58]
+
+It was a good look at using the compiler and practice, like, not even the focus on the performance, but what is it like behavior wise? [01:31:28]
+
+## Great history of web dev: [30 Years of
Tags](https://www.artmann.co/articles/30-years-of-br-tags)
+
+**Mark:** I've always been a very big fan of history stuff. That's kind of my shtick at this point, and. Someone put together a really long, really good post titled 30 Years of BR Tags and it's, a look back at like all the history of web development from handwritten HTML and Pearl and CGI bin to Web 2.0 and PHP to, Java stacks to react and next and everything else. [01:31:36]
+
+It's great to see just the history of all the pieces and the mindsets and the problems and the tools that we've invented to try to solve all those problems in one place. I, I love that kind of post. [01:32:04]
+
+**Carl:** Yeah. [01:32:17]
+
+## Nadia Makarevich’s latest deep dive: [Bundle Size Investigation](https://www.developerway.com/posts/bundle-size-investigation)
+
+**Carl:** And uh, Nadia Makarevic did a really good blog post talking about bundle size investigation. This is like near and dear to my professional career. [01:32:18]
+
+have done this so many times because If you don't think about bundle size, then it will cause you problems. This is a really good, like up to date explanation of the problem. You'd naively set up a project and add a forum and oh my God, it's over five megabytes, uncompressed, and still a megabyte after you compress it. So, like it's really , a downside of the JavaScript ecosystem, having really good package management is that it's really easy a lot of code. [01:32:26]
+
+So you have to consciously think about how to prune the code you're using. I feel like I could have read a blog post like this in 2016. I certainly did. It's got a good bit talking about analyzing bundle size and using these visualizers to show, to reveal what is contributing to the overall size of the bundle in a nice visual hierarchical way through like nested boxes, tree maps, flame graphs for, I guess that's more execution time, stack. [01:32:55]
+
+Yeah, really good. If you, I don't know, want to be thoughtful about how much data you're sending, this is a good technical writeup of an expert doing it. [01:33:25]
+
+## [Extensive ES2026 feature preview](https://thenewstack.io/es2026-solves-javascript-headaches-with-dates-math-and-modules/)
+
+**Carl:** Cool. We've got a big feature preview for ES 2026. This is an article from the New Stack, which is a, it feels like a tech journalism outlet in a way that is not common at all. So, uh, yeah, I appreciate them. [01:33:35]
+
+They put out a, a post talking about ES 26 solves JavaScript headaches with dates, math and modules. [01:33:48]
+
+So love that. I have problems with dates, math and modules all the time. I need to, well, I don't, I'm not finding an actual list of things that will be coming out. I guess they've got like a, a better precision for summing values and math tools. [01:33:55]
+
+**Mark:** Temporal is the big one. [01:34:12]
+
+**Carl:** I am excited for temporal. I'm currently running into a problem where locally when I do `Date.now()` I get something in my local EST time zone. But all of the database things are in UTC. So it is, there's, it thinks things are happening at a five hour offset from when they are, which won't happen in production. And that's an example of how JavaScript sucks at dates. [01:34:14]
+
+So I am excited for temporal because date.now should not always rely on your systems time zone. We need a way to encode time zones and date objects and JavaScript. We need it. It's so painful. So yeah. Exciting. Hopefully we'll get that. [01:34:36]
+
+## [React reconciler for Blender 3D](https://romanliutikov.com/blog/driving-3d-scenes-in-blender-with-react)
+
+**Mark:** Recently mentioned examples of people doing someone did a React reconcile or for the Dear Image gooey tool that's GUI is for c plus plus that where, where everything gets redrawn, every frame. Meanwhile, someone did a React renderer for controlling blender with react. I think this is als. [01:34:53]
+
+Looking at the examples appear to be written in closure or closure script instead of JSX. And I think I've seen some posts from this author where they've previously talked about using react from closure script as well. So more examples of things you did not know you could do with react. [01:35:13]
+
+**Carl:** Love it. [01:35:30]
+
+## [The “why” of React Fiber](https://x.com/infinterenders/status/1997359890021634509)
+
+**Carl:** I forgot we had this in the document, and I love that I basically said some of the things from it earlier. But somebody tweeted about react fiber and it's just a really good post. , it's very long. It's very like, casual and silly [01:35:31]
+
+**Mark:** and blog, post in tweet form. [01:35:46]
+
+**Carl:** Yeah. But I, I like it. I'm gonna read some passages. [01:35:49]
+
+"React Fiber is honestly one of those things that people think they get until they actually look under the hood. And then suddenly the whole thing feels like some alien technology living inside JavaScript. Everyone parrots those same cell lines, like react, like fiber is the new Diffing engine, or fiber is concurrent rendering. And it's just so much more deeper and more deranged than that." [01:35:52]
+
+Like yes it is. It's a fucking scheduler! Like who re implements a scheduler? It's, you should never do that. There's always better. There's always more robust battle test and schedulers. That's like some core compiler interpreter, computer science degree kind of stuff. Like don't re-implement those. Those are the foundations. [01:36:09]
+
+**Mark:** The other way to look is they basically reimplemented a JavaScript execution stack. [01:36:28]
+
+**Carl:** Yeah, they literally did that. Like I, I've seen people complain about how like sometimes when you're debugging React stuff, you can't use certain developer tools because React manages its own stack. Like [01:36:32]
+
+**Mark:** Boy, can I tell you about that one, thank you very much. It's what I've done at Replay for the last few years. [01:36:46]
+
+**Carl:** right. Like it's literally duplicating logic that like V eight or, I don't, I don't remember any of the other runtimes off the top of my head. [01:36:51]
+
+**Mark:** Monkey, JSC. [01:36:59]
+
+**Carl:** Thank you. So like it's re-implementing things that every other JavaScript app gets for free from the runtime environment that it's executing in. But because React transcends individual runtimes, they need to re-implement that themselves anyway. It's fascinating. This is a good little reminder that like there be dragons in this tool that we use constantly. [01:37:00]
+
+## Async React articles from [Aurora Scharff](https://blog.logrocket.com/the-next-era-of-react/) and [Jack Herrington](https://blog.logrocket.com/react-19-2-the-async-shift/)
+
+**Mark:** And finally at the two hour mark in this podcast. Thank you for those of you who have stuck with us. Ricky Hanlon's talk on Async React from React Con, I think was one of the biggest pieces of messaging from the React team and showing us where React has arrived at and where it's going to go in the next couple years. [01:37:21]
+
+And Aurora Scharf and Jack Harrington have both done a lot great work in learning and teaching a lot of React concepts, right? Aurora has done a lot of conference talks and blog posts on Modern React features, suspense, async behavior, et cetera. And so they, they both put up blog posts on Blog Rocket within the last month or two talking about modern async React and what does it look like? What are the primitives, how do they fit together? How does this actually improve your code base? And what, why should you be using these things in your apps? [01:37:42]
+
+And with that, I think we may finally, finally be done [01:38:16]
+
+**Carl:** we're done. We're done. We did it. We did two hours of talking about React and by God we got it. [01:38:20]
+
+**Mark:** Was, was this ever in doubt?? [01:38:26]
+
+**Carl:** I mean, no, it's, yeah. This was good. I, I'm, I'm happy with this one. was good. Felt like a good chat. [01:38:28]
+
+Thank you everyone for joining us. Even I, I can't believe we still have what, 10 people here listening to us do appreciate you, like genuinely. [01:38:34]
+
+We will be back next month, I guess, in like six weeks at time of recording. But yeah, we'll be back here on the stage, back in your podcast feed just as soon as we can. And happy holidays. Merry Christmas. If you celebrate. Happy Hanukkah. If you, that's what you celebrate. [01:38:43]
+
+**Mark:** Happy holidays folks. Thanks for listening to us. Thanks for being part of React Flux and part of the React community, and we continue to hope that hearing the three of us up here ramble is informative and provides value to you as a professional developer or non-professional developer as the case may be. [01:38:58]
+
+**Carl:** Hopefully it's, I don't know, entertaining. We're, we're some fun personalities. We can be, we can be fun and useful. [01:39:14]
+
+Thank you so much. If you see anything that is newsworthy that you think we should discuss let us know in the #tech-reads-and-news channel here in Reactiflux. [01:39:20]
+
+Or you can send me an email at hello@reactiveflux.com. I read everything that comes in, so if you send it, I'll read it. This is a show that you get value from and wanna support. Best way to do so is by submitting a review on whatever platform you're listening to us on, and tell your friends and coworkers about us. [01:39:27]
+
+Go to a meetup, say, "Hey, I like this podcast." Awesome. Thanks so much. See you next month. [01:39:42]
+
+See you year. [01:39:47]